Created attachment 517218 [details] /var/db/pkg/net-firewall/ebtables-2.0.10.4/NEEDED.ELF.2 If a file links to an internal library in runpath which lacks an soname, LinkageMapELF sees it as a broken soname dependency: > > $ emerge -p --depclean --ignore-soname-deps=n > > Calculating dependencies... done! > * Broken soname dependencies found: > * > * x86_64: libebt_redirect.so required by: > * net-firewall/ebtables-2.0.10.4 > * > * x86_64: libebt_log.so required by: > * net-firewall/ebtables-2.0.10.4 However, ldd sees the dependencies as resolved: > $ ldd /sbin/ebtables > linux-vdso.so.1 (0x00007ffd6e763000) > libebtc.so => /lib64/ebtables/libebtc.so (0x00007f015f82d000) > libebt_802_3.so => /lib64/ebtables/libebt_802_3.so (0x00007f015f62b000) > libebt_nat.so => /lib64/ebtables/libebt_nat.so (0x00007f015f428000) > libebt_arp.so => /lib64/ebtables/libebt_arp.so (0x00007f015f224000)
It seems like this needs to be implemented in the SonameDepsProcessor._intersect method, since these sonames should not be exported in PROVIDES metadata, and they need to be excluded from REQUIRES metadata.
A simple way to solve the problem for ebtables is with REQUIRES_EXCLUDE in the ebuild: REQUIRES_EXCLUDE="/lib*/ebtables/*.so" However, given that ldd automatically handles these links, it's appealing to have portage handle these links in a compatible way.
Actually, the REQUIRES_EXCLUDE setting for ebtables would have to be more like this: REQUIRES_EXCLUDE="libebt*.so" If we recognize the file names of these libraries as a sort of implicit soname (like ldd does), then we also need to exclude these libraries from PROVIDES. However, how do we know that it is appropriate to exclude them from PROVIDES? Perhaps the ebuild will have to specify this with a PROVIDES_EXCLUDE setting like one the following: # match by implicit soname PROVIDES_EXCLUDE="libebt*.so" # match by file path PROVIDES_EXCLUDE="/lib*/ebtables/*.so"
In order to avoid the need for any REQUIRES_EXCLUDE or PROVIDES_EXCLUDE settings in the ebuild, we can use the following rules: 1) Files without an explicit DT_SONAME field should be used to satisfy dependencies internal to the package when appropriate DT_RUNPATH/DT_RPATH entries exist, and the satisfied dependencies should be excluded from REQUIRES. Also LinkageMapELF should recognize that these dependencies are satisfied. 2) Files without an explicit DT_SONAME field should not be included in PROVIDES (therefore there's no need to exclude them with PROVIDES_EXCLUDE).
I've posted a patch for review that will fix SonameDepsProcessor to automatically exclude these internal dependencies from the REQUIRES metadata: https://archives.gentoo.org/gentoo-portage-dev/message/8a8aae867ce4106c272fd195392de69d https://github.com/gentoo/portage/pull/322
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=1364cd44e7a6232bf425c4573b5bd3d6738d49a4 commit 1364cd44e7a6232bf425c4573b5bd3d6738d49a4 Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2018-05-20 06:40:19 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2018-05-24 20:31:02 +0000 SonameDepsProcessor: handle internal libs without DT_SONAME (bug 646190) Packages like ebtables have internal libraries that lack a DT_SONAME field in their ELF header. Consumers of these internal libraries have DT_RUNPATH entries that refer to the directory containing the internal libraries. For library dependencies that are satisfied by internal libraries like this, it is inappropriate for SonameDepsProcessor to include these depenedencies in the REQUIRES metadata, therefore fix SonameDepsProcessor to automatically detect this case and exclude these dependencies from the REQUIRES metadata. This solves incorrect reporting of broken soname dependencies like the following: $ emerge -p --depclean --ignore-soname-deps=n Calculating dependencies... done! * Broken soname dependencies found: * * x86_64: libebt_redirect.so required by: * net-firewall/ebtables-2.0.10.4 * * x86_64: libebt_log.so required by: * net-firewall/ebtables-2.0.10.4 Bug: https://bugs.gentoo.org/646190 pym/portage/tests/util/dyn_libs/__init__.py | 0 pym/portage/tests/util/dyn_libs/__test__.py | 0 .../tests/util/dyn_libs/test_soname_deps.py | 34 +++++++++++++++++++++ pym/portage/util/_dyn_libs/soname_deps.py | 35 ++++++++++++++++++++-- 4 files changed, 66 insertions(+), 3 deletions(-)
Fixed in portage-2.3.40-r1.
(In reply to Larry the Git Cow from comment #6) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/proj/portage.git/commit/ > ?id=1364cd44e7a6232bf425c4573b5bd3d6738d49a4 > > commit 1364cd44e7a6232bf425c4573b5bd3d6738d49a4 > Author: Zac Medico <zmedico@gentoo.org> > AuthorDate: 2018-05-20 06:40:19 +0000 > Commit: Zac Medico <zmedico@gentoo.org> > CommitDate: 2018-05-24 20:31:02 +0000 > > SonameDepsProcessor: handle internal libs without DT_SONAME (bug 646190) We can revert this if we merge a patch for bug 715162 which covers both internal and external libraries.
