# scanelf -n /opt/eagle/bin/eagle TYPE NEEDED FILE ET_EXEC libXrender.so.1,libXrandr.so.2,libXcursor.so.1,libfreetype.so.6,libfontconfig.so.1,libXext.so.6,libX11.so.6,libdl.so.2,libXi.so.6,libpthread.so.0,librt.so.1,libssl.so.1.0.0,libcrypto.so.1.0.0,libcups.so.2,libz.so.1,libX11-xcb.so.1,libxcb.so.1,libm.so.6,libgcc_s.so.1,libc.so.6,ld-linux-x86-64.so.2 /opt/eagle/bin/eagle As you can see, the "eagle" binary is linked to libssl.so.1.0.0 and libcrypto.so.1.0.0. These files are not installed by dev-libs/openssl-1.1.0j. Now sci-electronics/eagle-7.7.0 is perpetually in Portage's @preserved-rebuild set because it can't use libssl.so.1.1 and libcrypto.so.1.1. It seems that we need a libraries-only SLOT="1.0.0" of dev-libs/openssl similar to the SLOT="0.9.8" of the same.
Now that Bug #662246 is closed, we have a dev-libs/openssl-1.0.2q-r200:1.0.0 ebuild that can satisfy the binary dependency of sci-electronics/eagle-7.7.0. Please make the following change to the sci-electronics/eagle ebuild(s): --- sci-electronics/eagle/eagle-7.7.0.ebuild~ 2018-01-12 11:40:07.000000000 +0000 +++ sci-electronics/eagle/eagle-7.7.0.ebuild 2019-01-03 11:57:10.260737360 +0000 @@ -21,7 +21,7 @@ RDEPEND=" sys-libs/glibc - dev-libs/openssl:0 + || ( =dev-libs/openssl-1.0*:0 dev-libs/openssl:1.0.0 ) >=sys-libs/zlib-1.2.8-r1 >=media-libs/freetype-2.5.0.1 >=media-libs/fontconfig-2.10.92
openssl-1.1.1d-r1 went stable now and the proposed patch is not applied to eagle. emerge now keeps complaining: !!! existing preserved libs: >>> package: dev-libs/openssl-1.1.1d-r1 * - /usr/lib64/libcrypto.so.1.0.0 * used by /opt/eagle/bin/eagle (sci-electronics/eagle-7.3.0) * - /usr/lib64/libssl.so.1.0.0 * used by /opt/eagle/bin/eagle (sci-electronics/eagle-7.3.0) Use emerge @preserved-rebuild to rebuild packages using these libraries
It seems that they added an openssl-compat (similar to ncurses-compat) package which installs the older library only for just such binary problems. I think the ebuild(s) should actually be upgraded to: || ( =dev-libs/openssl-1.0*:0 dev-libs/openssl-compat:1.0.0 ) Until that gets into the tree, you can workaround this by doing the following: 1) emerge -ca eagle - This will let portage get rid of the libssl/crypto.so.1.0.0 owned by openssl 2) emerge -1 openssl-compat:1.0.0 - This will install just the binaries from the 1.0.0 package that eagle needs 3) emerge eagle Note, that since we didn't add openssl-compat the the world (emerge -1), portage will want to depclean it. I recommend not adding it, and let the (eventual) ebuild fix handle the dep correctly. Worked for me here. YMMV.
This is the correct way of handling it. If you want, you can create a local overlay, editing the dependency to dev-libs/openssl-compat:1.0.0. This is kind of a duplicate of bug 685952
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=78b0e0e369092d957e48d195b691fec12546a09e commit 78b0e0e369092d957e48d195b691fec12546a09e Author: Christophe Lermytte <gentoo@lermytte.be> AuthorDate: 2020-01-26 21:39:27 +0000 Commit: David Seifert <soap@gentoo.org> CommitDate: 2020-01-26 21:39:27 +0000 sci-electronics/eagle: depend on OpenSSL 1.1 Bug: https://bugs.gentoo.org/673892 Closes: https://github.com/gentoo/gentoo/pull/14354 Signed-off-by: David Seifert <soap@gentoo.org> sci-electronics/eagle/{eagle-7.3.0.ebuild => eagle-7.3.0-r1.ebuild} | 4 ++-- sci-electronics/eagle/{eagle-7.4.0.ebuild => eagle-7.4.0-r1.ebuild} | 4 ++-- sci-electronics/eagle/{eagle-7.6.0.ebuild => eagle-7.6.0-r1.ebuild} | 4 ++-- sci-electronics/eagle/{eagle-7.7.0.ebuild => eagle-7.7.0-r1.ebuild} | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-)
This fix didn't actually require a rev bump, did it? No sense in making everyone re-emerge a package that doesn't need to be rebuilt just to add a runtime dependency.
(In reply to Matt Whitlock from comment #6) > This fix didn't actually require a rev bump, did it? No sense in making > everyone re-emerge a package that doesn't need to be rebuilt just to add a > runtime dependency. https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html (...) Examples of changes that warrant a new revision are: (...) * adding a missing runtime dependency to one of the existing blocks (...)
(In reply to Kobboi from comment #7) > (In reply to Matt Whitlock from comment #6) > > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html Interesting! Thanks for digging that up. It actually seems like it could be outdated. Portage has no problem adding new runtime dependencies for already installed packages. I would agree that adding a new *build-time* dependency warrants a new revision, as some means is needed to prompt the package manager to rebuild the affected package, but adding a *runtime* dependency doesn't logically require rebuilding the affected package. Perhaps this section of the developer manual needs to be revisited. Thanks again.
(In reply to Matt Whitlock from comment #8) > (In reply to Kobboi from comment #7) > > (In reply to Matt Whitlock from comment #6) > > > > https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html > > Interesting! Thanks for digging that up. It actually seems like it could be > outdated. Portage has no problem adding new runtime dependencies for already > installed packages. I would agree that adding a new *build-time* dependency > warrants a new revision, as some means is needed to prompt the package > manager to rebuild the affected package, but adding a *runtime* dependency > doesn't logically require rebuilding the affected package. Perhaps this > section of the developer manual needs to be revisited. Thanks again. It's to ensure that Portage is satisfied by changes to other packages forcing an upgrade/downgrade. Portage will happily do what you said but this isn't required by PMS and hence can't be relied on. Anyway, this is fixed now.
*** Bug 685952 has been marked as a duplicate of this bug. ***
