Bug 653200 – portage: QA check for NEEDED.ELF.2 not in RDEPEND or @system

• Product: Portage Development
• Status: CONFIRMED ---

[Description Martin Väth 2018-04-15 05:28:35 UTC]

It is (almost) always a bug if there is a library listed in NEEDED.ELF.2 which is not explicitly listed in RDEPEND (or in @system):
The only exceptions I can think of are packages compiled without -Wl,--as-needed (although one can argue whether packages requiring this shouldn't have a correspondingly enlarged RDEPEND), or binary packages which must get exceptions from such QA checks anyway.

Such a check would help to reduce the number of undetected "automagic" dependencies (currently a search for "automagic" yields 74 open bugs, but I guess many are not reported or never detected).

At least, it would be nice if there would be a script a developer can run.

Implementation-wise, for speed reasons, it might be a good idea to manage a cache of all @system libraries (according to /var/db) (for a separate script, it be enough to have this cache in RAM). Then one just has to add the RDEPEND libraries (according to /var/db) to that cache as a set (hashed, e.g. as a python set) and go through the actually used libraries whether there are misses.

[Comment 1 Arfrever Frehtes Taifersar Arahesis 2018-04-17 05:40:42 UTC]

Some kind of dependency resolution for some packages (often virtuals) would be needed.

E.g. @system set contains virtual/libc, but not sys-libs/glibc, sys-libs/musl etc., but libc.so belongs to sys-libs/glibc, sys-libs/musl etc.

(Special handling based on category should be avoided...)

[Comment 2 Martin Väth 2018-04-17 08:08:29 UTC]

Depending on USE-flags, the dependency list might become too long.

An alternative might be to maintain a hardcoded list of "allowed" @system libraries (either in portage or in the profile): I suppose that the list would not be much more than the various libc+compiler libraries.
Such a list would eliminate the most complicated step in the implementation.

[Comment 3 Arfrever Frehtes Taifersar Arahesis 2018-04-17 17:11:40 UTC]

The aforementioned situation also affects virtuals not in @system set.

E.g. packages which use libudev.so should directly depend on virtual/libudev, not sys-fs/udev, sys-apps/systemd, sys-fs/eudev.

[Comment 4 Arfrever Frehtes Taifersar Arahesis 2018-04-17 17:17:38 UTC]

Beside "virtual" category, there is also "java-virtuals" category.
It is not impossible that there will be more virtual categories in the future.

PROPERTIES="virtual" [1] could be used...

[1] https://archives.gentoo.org/gentoo-dev/message/9d449a18a96a25a547fcfd40544085cf

[Comment 5 Sam James 2022-03-05 07:13:35 UTC]

While this hasn't been implemented in Portage itself, app-portage/iwdevtools does handle this.

(I started an implementation about a year ago - no idea if I've still got it - but wasn't happy with the complexity being added, given that ideally it'd be on the Bash side like the rest of our QA checks.)

[Comment 6 Sam James 2022-03-05 07:26:33 UTC]

*** Bug 234269 has been marked as a duplicate of this bug. ***