Re: [gentoo-dev] ssl vs openssl vs libressl vs gnutls USE flag foo

[Michał Górny]

On Fri, 30 Oct 2015 18:25:14 -0400
Rich Freeman <rich0@g.o> wrote:

> On Fri, Oct 30, 2015 at 5:16 PM, Anthony G. Basile <blueness@g.o> wrote:
> > On 10/30/15 3:35 PM, hasufell wrote:
> >>
> >> On 10/30/2015 06:55 PM, Michał Górny wrote:
> >>>
> >>> We have no way of saying 'I prefer polarssl, then gnutls, then
> >>> libressl, and never openssl'.
> >>
> >> I don't think this is something that can be reasonably supported and it
> >> sounds awfully automagic. And I don't see how this is possible right
> >> now, so I'm not really sure what you expect to get worse.
> >>
> >> E.g. -gnutls pulling in dev-libs/openssl is not really something you'd
> >> expect. If we go for provider USE flags, then things become consistent,
> >> explicit and unambiguous. The only problem is our crappy implementation
> >> of providers USE flags via REQUIRED_USE.
> >>
> > I'm not sure what mgorny has in mind, but the problem I see with saying I
> > want just X to be my provider system wide is that some pkgs build with X
> > others don't, other pkgs might need a different provider.  So it might make
> > sense to order them in terms of preference: X1 > X2 > X3 ... and then when
> > emerging a package, the first provider in the preference list that works is
> > pulled in for that package.
>
> I think that would be useful in general.  It would probably not be
> useful in this case, since it was somebody's bright idea to make it
> essentially impossible to install two of the options on the same
> system (and that wasn't directed at hasufell).  Users could of course
> still express the preference, but the PM would need to be smart enough
> to ignore that preference on 95% of packages that support both options
> so that it can take the lower preference on the 5% of packages that
> only support the option the user didn't really want.

No, that's not *the* problem. LibreSSL vs OpenSSL is actually
the *least* problematic one since we intend to support them as
'drop-in-plus-rebuild' replacements.

The real problem is those fancy upstreams who believe they're doing
everyone a favor by providing the choice between multiple SSL
providers. This is what brings the real conflicts here, and this what
often loves to break stuff even further by introducing cross-package
implementation match requirements...

-- 
Best regards,
Michał Górny
<http://dev.gentoo.org/~mgorny/>