1 |
> > a) The two cannot be installed concurrently. To fix that would require |
2 |
> > even |
3 |
> > more hacks. |
4 |
> |
5 |
> As we've discussed in another part of the thread, that's not really true. |
6 |
> Both can for sure be installed, just not in the same place and/or |
7 |
> with same names. |
8 |
|
9 |
Exactly that is what would require even more hacks. Given how many different |
10 |
and more or less hackish build systems exist in the Gentoo tree, this is just |
11 |
not feasible. |
12 |
|
13 |
> > -> all relevant ssl consumers on the user's system must be linked against |
14 |
> > the one selected |
15 |
> |
16 |
> Also not the case. Considering the two installed in different paths |
17 |
> with same names it's still easy for consumers to use one or the other |
18 |
> with -rpath at link time. |
19 |
|
20 |
Dito... |
21 |
|
22 |
Please remember, the point is to keep this somewhat maintainable. |
23 |
|
24 |
> > c) If a single package that the user wants to install is not "fixed" for |
25 |
> > one ssl library, it blocks that option for all packages. |
26 |
> |
27 |
> Please think of a libressl ebuild in a new way. |
28 |
|
29 |
Well, if it just drops the library somewhere where nothing can use it... that |
30 |
can for sure be done, but also does not really help anyone. |
31 |
|
32 |
> > I guess if you can come up with a solution that |
33 |
> > * provides secure usage of the libraries, |
34 |
> > * provides choice to the user, and |
35 |
> > * doesn't lead to unupgradeable systems or unresolvable dependencies |
36 |
> > we'd all be happier. So far we haven't found one. |
37 |
> |
38 |
> Right! I think letting a libressl ebuild install only libtls could be a |
39 |
> good start, because it provides a stable situation, without risking |
40 |
> conflicts. Would you agree? |
41 |
|
42 |
No idea to be honest, and not much opinion on this. |
43 |
|
44 |
|
45 |
-- |
46 |
Andreas K. Hüttel |
47 |
dilfridge@g.o |
48 |
Gentoo Linux developer |
49 |
(council, qa, toolchain, base-system, perl, libreoffice) |