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.