Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 673892 - sci-electronics/eagle-7.7.0 dependency on dev-libs/openssl:0 is not satisfied by >=dev-libs/openssl-1.1
Summary: sci-electronics/eagle-7.7.0 dependency on dev-libs/openssl:0 is not satisfied...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: The Soldering-Iron Brotherhood
URL:
Whiteboard:
Keywords: PullRequest
Depends on: 662246
Blocks:
  Show dependency tree
 
Reported: 2018-12-28 15:20 UTC by Matt Whitlock
Modified: 2020-05-03 18:03 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Whitlock 2018-12-28 15:20:43 UTC
# 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.
Comment 1 Matt Whitlock 2019-01-03 12:04:47 UTC
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
Comment 2 Manuel Mommertz 2019-10-08 12:54:23 UTC
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
Comment 3 David Flogeras 2019-10-08 22:14:03 UTC
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.
Comment 4 Christian Schmidt 2019-11-06 10:28:45 UTC
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
Comment 5 Larry the Git Cow gentoo-dev 2020-01-26 21:39:43 UTC
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(-)
Comment 6 Matt Whitlock 2020-01-26 22:08:08 UTC
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.
Comment 7 Kobboi 2020-05-03 10:46:36 UTC
(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
(...)
Comment 8 Matt Whitlock 2020-05-03 18:03:06 UTC
(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.