Gentoo is unable to migrate to v1.1 at this moment because bunch of software was not upgraded yet. There are hundred patches flying around, but they are untrusted and not approved by upstreams. Major vendors such as ruby/apache/ssh/wpa_supplicant hasn't moved yet, I'm not even talking about a less important and less popular software. Even worst, v1.0 will be out of support and it is very likely that the bug https://bugs.gentoo.org/show_bug.cgi?id=openssl-1.1 will not be resolved timely. I think it makes much more sense to invest extra time and slot v1.1 to a separate slot instead of accepting these random patches and dealing with complex crypto problems potentially. And even today, there is a software which requires v0.9.8 so 1.0 will not go away just like that either. Here is a post with the claim that there is a patch to slot it: http://openssl.6102.n7.nabble.com/openssl-1-0-and-1-1-co-exist-td71194.html The new API need to be in a new slot. This is always been a philosophy of Gentoo.
Here is the patch: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=822b5e2645a99bea15329bd66c9723c7e7119cdb
(In reply to Anton Bolshakov from comment #1) > Here is the patch: > > https://git.openssl.org/?p=openssl.git;a=commitdiff; > h=822b5e2645a99bea15329bd66c9723c7e7119cdb my bad, this patch was already accepted and it is part of the openssl 1.1. But we still need to change a default location of include files (at least)
+1 I also would vote for a different SLOT.
The one big problem I see here is how applications should choose the correct openssl slot. There's the way via pkg-config which alone gives headaches because of how openssl's pkg-config files are named: # qlist -Ce openssl | grep "\.pc$" /usr/lib/pkgconfig/libcrypto.pc /usr/lib/pkgconfig/libssl.pc /usr/lib/pkgconfig/openssl.pc /usr/lib64/pkgconfig/libcrypto.pc /usr/lib64/pkgconfig/libssl.pc /usr/lib64/pkgconfig/openssl.pc # qlist -CIve openssl dev-libs/openssl-1.1.1 As you can see, the .pc files come without a version name so the pkg-config call is allways: pkg-config <--libs|--cflags> <libcrypto|libssl|openssl> How should applications using pkg-config to look for openssl do so for older or newer versions? We cannot let multiple openssl slots install the same .pc files. We would have to rename them which then breaks most build systems relying on the generic .pc file names. What about applications that search for the libs directly without pkg-config? Do you expect us to change the build system of each and every package that requires an openssl version different to the "main" version? That will quickly become a massive maintenance burden which I doubt many Gentoo developers are willing to take. I'm quite sure that technically, installing different openssl versions is not that hard. But I doubt there is an easy way to make applications aware of the "right" openssl version to use.
> We would have to rename them which then breaks most build systems > relying on the generic .pc file names. A few build systems of 1.0-only packages have to be patched to catch the renamed .pc files. This is not a big deal. Especially not when you compare it with the amount of work to patch 1.0-only packages to 1.1: There are some (e.g. wvstreams) where this is close to impossible.
Or we can use virtual .pc files like symbol links and change it depends on build. (probably we should have a special mechanism for that but I suppose it possible)
Hi, This is now more necessary with nodejs-9 being removed from the tree due to vulnerabilities: https://bugs.gentoo.org/672136 As of now, it's nearly impossible to get a working Gentoo system with both a secure version of nodejs, and a bunch of common applications which still depends on openssl-1.0. Please do something about this.
@Lars: You already have a precedent in dev-libs/openssl-0.9.8z_p8-r1 for exactly what we need: install *only* lib{crypto,ssl}.so.1.0.0 and no other files by the SLOT="1.0.0" ebuild. The SLOT="0" ebuild (i.e., current development version) should be the only one that installs headers and pkg-config files, etc. As a point of reference, sys-libs/ncurses did a similar thing when Ncurses 6 was released: the sys-libs/ncurses:5 ebuild now only installs the shared libraries, while the sys-libs/ncurses:0 ebuild installs everything.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f57daf324db6e5c83e0587bf84acecd094707556 commit f57daf324db6e5c83e0587bf84acecd094707556 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2019-01-02 21:28:53 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2019-01-02 21:29:21 +0000 dev-libs/openssl: Added slotted openssl-1.0.2q (SLOT="1.0.0") Closes: https://bugs.gentoo.org/662246 Package-Manager: Portage-2.3.53, Repoman-2.3.12 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> dev-libs/openssl/openssl-1.0.2q-r200.ebuild | 248 ++++++++++++++++++++++++++++ 1 file changed, 248 insertions(+)
