Bug 35484 – Implement a reverse dependency tracker using LDD information and compare it against the run-time dependencies listed in the ebuild.

• Product: Portage Development
• Status: RESOLVED FIXED

[Description Spider (RETIRED) 2003-12-09 14:59:55 UTC]

The idea is simple:
With a given set of USE flags (taken from portage, most conveniently)  scan a given binary file for all library links (ldd)  track each library to its package and build a tree of RDEPEND from this.

Compare this to portage's idea of what USE flags + RDEPEND are actually in the build, when theese two match, we have a "perfect" tree with no breakage.

When there are packages in the calculated (on disk) RDEPEND tree that -dont-  match portage's idea of RDEPEND, we have a broken dependency somewhere along the tree path.

[Comment 1 Alastair Tse (RETIRED) 2003-12-09 15:02:56 UTC]

i think this is good, except that it won't work on statically compiled libraries/binaries and also scripts like python or perl. but that is probably the best we can do.

[Comment 2 Karl Trygve Kalleberg (RETIRED) 2004-02-07 19:16:25 UTC]

This also won't work for Java.

However, it's a very good start. 

A second possiblity that we're also exploring is this:

Build *all* packages in the tree, one by one. Each time we build a new package, we ensure we have a "minimal tree". A minimal tree for a package foo, is a tree containing all of foo's DEPENDs, say package set X. For each package y in X, we ensure that we have y's RDEPENDs installed, recursively.

This way, we should catch any build-time problems of messed up RDEPEND settings. However, we do not properly test run-time problems; some applications may dynamically load extra functionality not invoked at build-time.

This is really a QA bug, so I'll see where I can forward it, possibly with a few scripts.

[Comment 3 Alec Warner (RETIRED) 2006-04-24 10:57:05 UTC]

I'll look into ferringb's pkgcore depresolver for this.  We should be able to walk the tree backwards and do it?

[Comment 4 [e-mail] 2008-02-25 16:56:37 UTC]

(In reply to comment #3)
> I'll look into ferringb's pkgcore depresolver for this.  We should be able to
> walk the tree backwards and do it?

Alec, any progress? :)

[Comment 5 Tom Wijsman (TomWij) (RETIRED) 2013-07-06 19:14:43 UTC]

Ping, any progress on this?

[Comment 6 Brian Dolbec (RETIRED) 2013-07-06 19:27:12 UTC]

No one is working on this that I know of.

[Comment 7 Sam James 2022-03-05 07:13:52 UTC]

https://bugs.gentoo.org/653200#c5

[Comment 8 Sam James 2022-03-05 07:25:53 UTC]

Actually, I dare say this is really fixed with app-portage/iwdevtools. The request wasn't for Portage itself to have it.

There's also https://github.com/gentoo/kde/blob/master/Documentation/maintainers/dynlink-scanner.