This is an issue that keeps popping up, and needs to be clarified -- putting it here on the bug tracker at the request of @blueness. Specifically, it is unclear what the libressl, openssl, and gnutls use flags mean, and what their relationship is to the ssl USE flag. In addition, what USE flags should be used when the user has installed libressl and is using it as a libcrypto provider? Should we still be using the libressl USE flag? Discussion on this topic has happened in https://bugs.gentoo.org/569818 https://github.com/gentoo/gentoo/pull/2726 https://github.com/gentoo/gentoo/pull/2689 and other places.
The semantics of USE=libressl have always been clear, namely that it is a implementation-discriminating flag between dev-libs/openssl and dev-libs/libressl. This has been documented in multiple places and is not up for debate: https://wiki.gentoo.org/wiki/Project:LibreSSL https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots#ABI-incompatible_library_variants Compare this to the USE=ffmpeg/libav and USE=imagemagick/graphicsmagick situation, where libav and graphicsmagick act as implementation-discriminating flags. The relationship between USE=openssl/gnutls(/polarssl) is less well defined. Currently, there are no global unified semantics here. The main problem is the "impossible trinity": 1. maintainer choice 2. upstream recommendation 3. globally uniform semantics Some ebuilds go the way of REQUIRED_USE="^^ ( openssl gnutls polarssl )" or REQUIRED_USE="ssl? ( ^^ ( openssl gnutls polarssl ) )", which is ugly but can at least satisfy 3. and one of 1./2. Some ebuilds have cascades, which violates 3. but allows for 1. I don't have any good ideas on how solve this trilemma.
(In reply to David Seifert from comment #1) If you want to have the libav useflag semantics, then I'd say it is already solved: openssl means "enable openssl related features" (~= ffmpeg useflag) libressl means "use libssl as openssl provider" (~= libav useflag) meaning: REQUIRED_USE="ssl? ( ^^ ( openssl libressl gnutls polarssl ) )" is wrong and should be replaced by: REQUIRED_USE="ssl? ( ^^ ( openssl gnutls polarssl ) ) libressl? ( openssl )" i.e. the curl way is wrong (not sure if there are examples of the above outside of curl), and users are expected to enable both openssl and libressl useflags for libressl; the wiki link you posted doesn't seem to mention that The most important part above is that it is perfectly valid for USE="-openssl libressl" to fail at required use or disable libssl/libcrypto support altogether and users should be aware of that.
(In reply to Alexis Ballier from comment #2) > (In reply to David Seifert from comment #1) > > If you want to have the libav useflag semantics, then I'd say it is already > solved: > > openssl means "enable openssl related features" (~= ffmpeg useflag) > libressl means "use libssl as openssl provider" (~= libav useflag) > > meaning: > REQUIRED_USE="ssl? ( ^^ ( openssl libressl gnutls polarssl ) )" > is wrong and should be replaced by: > REQUIRED_USE="ssl? ( ^^ ( openssl gnutls polarssl ) ) libressl? ( openssl )" > > i.e. the curl way is wrong (not sure if there are examples of the above > outside of curl), and users are expected to enable both openssl and libressl > useflags for libressl; the wiki link you posted doesn't seem to mention that > > > The most important part above is that it is perfectly valid for > USE="-openssl libressl" to fail at required use or disable libssl/libcrypto > support altogether and users should be aware of that. Libressl already uses libav-semantics, and the latter "libressl? ( openssl )" clause is unnecessary. The question is not about how Libressl should be handled (this is non-ambiguous), but rather how the choice between OpenSSL (incl. LibreSSL) GnuTLS and PolarSSL should be handled.
(In reply to David Seifert from comment #3) > Libressl already uses libav-semantics, and the latter "libressl? ( openssl > )" clause is unnecessary. Why is it unnecessary ? > The question is not about how Libressl should be > handled (this is non-ambiguous), but rather how the choice between OpenSSL > (incl. LibreSSL) GnuTLS and PolarSSL should be handled. Well, then libressl doesn't come into the play at all here. Bug #569818 has been invalid all along (USE='-openssl libressl' disabling libressl is the expected behavior, yet nobody from the libressl team cared to reply) and the ssl case is not much different than USE='ffmpeg gstreamer libav' for a media player. Yet, I can find a lot of packages implementing this libressl useflag semantics with an openssl useflag specifically mentioning dev-libs/openssl or at least being ambiguous. But then again, you claim that how libressl is handled is non-ambiguous but no documentation nor communication has been made to make that clear. Note that for defining the semantics of a useflag the only thing to do is actually to define (and uniformize) it. Letting everyone define its own and hoping everybody happens to come up with the same definition is the worst thing that can happen.
(In reply to Alexis Ballier from comment #4) > (In reply to David Seifert from comment #3) > > Libressl already uses libav-semantics, and the latter "libressl? ( openssl > > )" clause is unnecessary. > > Why is it unnecessary ? Because it forces libcrypto support on people who use USE=libressl as a generic 'I prefer LibreSSL over OpenSSL'.
(In reply to David Seifert from comment #1) > The semantics of USE=libressl have always been clear, namely that it is a > implementation-discriminating flag between dev-libs/openssl and > dev-libs/libressl. This has been documented in multiple places and is not up > for debate: > https://wiki.gentoo.org/wiki/Project:LibreSSL > https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Subslots#ABI- > incompatible_library_variants > Compare this to the USE=ffmpeg/libav and USE=imagemagick/graphicsmagick > situation, where libav and graphicsmagick act as > implementation-discriminating flags. > > The relationship between USE=openssl/gnutls(/polarssl) is less well defined. > Currently, there are no global unified semantics here. The main problem is > the "impossible trinity": > > 1. maintainer choice > 2. upstream recommendation > 3. globally uniform semantics > > Some ebuilds go the way of REQUIRED_USE="^^ ( openssl gnutls polarssl )" or > REQUIRED_USE="ssl? ( ^^ ( openssl gnutls polarssl ) )", which is ugly but > can at least satisfy 3. and one of 1./2. Some ebuilds have cascades, which > violates 3. but allows for 1. I don't have any good ideas on how solve this > trilemma. Reassigning to QA, as we would want a solution for this "impossible trinity", which rears its ugly head in the GUI widgets discussion too. One suggestion to solve this has been the "weak REQUIRED_USE" proposition: https://archives.gentoo.org/gentoo-dev/message/61c843d69ad0bbd1c5968abb9fcbd325
