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.
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.
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.
I'll look into ferringb's pkgcore depresolver for this. We should be able to walk the tree backwards and do it?
(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? :)
Ping, any progress on this?
No one is working on this that I know of.
https://bugs.gentoo.org/653200#c5
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.
