> > a) The two cannot be installed concurrently. To fix that would require > > even > > more hacks. > > As we've discussed in another part of the thread, that's not really true. > Both can for sure be installed, just not in the same place and/or > with same names.
Exactly that is what would require even more hacks. Given how many different and more or less hackish build systems exist in the Gentoo tree, this is just not feasible. > > -> all relevant ssl consumers on the user's system must be linked against > > the one selected > > Also not the case. Considering the two installed in different paths > with same names it's still easy for consumers to use one or the other > with -rpath at link time. Dito... Please remember, the point is to keep this somewhat maintainable. > > c) If a single package that the user wants to install is not "fixed" for > > one ssl library, it blocks that option for all packages. > > Please think of a libressl ebuild in a new way. Well, if it just drops the library somewhere where nothing can use it... that can for sure be done, but also does not really help anyone. > > I guess if you can come up with a solution that > > * provides secure usage of the libraries, > > * provides choice to the user, and > > * doesn't lead to unupgradeable systems or unresolvable dependencies > > we'd all be happier. So far we haven't found one. > > Right! I think letting a libressl ebuild install only libtls could be a > good start, because it provides a stable situation, without risking > conflicts. Would you agree? No idea to be honest, and not much opinion on this. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
