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...
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
Keywords: PullRequest
Depends on: 662246
  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: ---


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
ET_EXEC,,,,,,,,,,,,,,,,,,,, /opt/eagle/bin/eagle

As you can see, the "eagle" binary is linked to and 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 and

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 @@
-	dev-libs/openssl:0
+	|| ( =dev-libs/openssl-1.0*:0 dev-libs/openssl:1.0.0 )
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/
 *      used by /opt/eagle/bin/eagle (sci-electronics/eagle-7.3.0)
 *  - /usr/lib64/
 *      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/ 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):

commit 78b0e0e369092d957e48d195b691fec12546a09e
Author:     Christophe Lermytte <>
AuthorDate: 2020-01-26 21:39:27 +0000
Commit:     David Seifert <>
CommitDate: 2020-01-26 21:39:27 +0000

    sci-electronics/eagle: depend on OpenSSL 1.1
    Signed-off-by: David Seifert <>

 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.

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)

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.