Created attachment 413366 [details, diff] xorg-server-1.17.2-r2.ebuild.diff this also fixes the slot on openssl
Not sure we want this. See also discussion in bug 512664 about allowing alternative crypto providers.
Are you saying you want to block a tree-wide conversion which no one really disagreed against on the dev ML? Rationale?
xorg-server does not use openssl as an SSL provider (cf. bug 512664 comment 1), so the discussion on the ML does not apply here I think. That being said, if it is impossible to install both libressl's and openssl's libcrypto on the same system, then there would be a point in supporting either (or some independent implementation).
(In reply to Chí-Thanh Christopher Nguyễn from comment #3) > xorg-server does not use openssl as an SSL provider (cf. bug 512664 comment > 1), so the discussion on the ML does not apply here I think. > > That being said, if it is impossible to install both libressl's and > openssl's libcrypto on the same system, then there would be a point in > supporting either (or some independent implementation). libressl is a drop-in replacement for openssl, it's not an alternative provider. If this patch cannot be applied, the whole conversion can be aborted, since the dep-graph will remain broken.
I think you should also add slot on libressl, since you can expect the slot you will use. Also slot operator for subslot changes.
(In reply to Julian Ospald (hasufell) from comment #4) > libressl is a drop-in replacement for openssl, it's not an alternative > provider. Help me to understand: why is libressl and openssl being chosen via a USE flag instead of a virtual/openssl meta package ? The relation between openssl and libressl is completely different than, say, with gnutls. To me, as a user, this decision appears inconsistent. > If this patch cannot be applied, the whole conversion can be aborted, since > the dep-graph will remain broken. I agree.
(In reply to Tolga Dalman from comment #6) > (In reply to Julian Ospald (hasufell) from comment #4) > > libressl is a drop-in replacement for openssl, it's not an alternative > > provider. > > Help me to understand: why is libressl and openssl being chosen via a USE > flag instead of a virtual/openssl meta package ? The relation between > openssl and libressl is completely different than, say, with gnutls. > > To me, as a user, this decision appears inconsistent. > > Refer to the mailing list, this is not a support channel.
Could the x11 team elaborate why this depends on bug 512664? Both things can be done separately, without blocking each other. The attached patch works and I am using it since more than half a year.
The only functionality xorg-server uses from OpenSSL is sha1 hashing, which is not removed from LibreSSL. I am using LibreSSL overlay and I had to patch just a few packages so that they would compile, xorg-server was never between them. Do we need to create special revision ebuilds? Why not just patch all of them?
I'll apply this patch in a few days, unless someone can explain to me what this breaks and why we should hold up a global conversion with an unrelated feature request.
We talked about it recently and there was little opposition to the change, other than bug #512664 where users might want to skip both openssl and libressl altogether. Since no one in the x11 herd really cares all that much about the SHA1 implementation used, adding libressl seems harmless.
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3260f63564e73c9c8ecdc72376de83c194b80f3
