Summary: | expose internal dependency tree for external tools | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Richard Benjamin Voigt <richardvoigt> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | enhancement | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Richard Benjamin Voigt
2005-01-23 22:46:43 UTC
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;) I see that equery depgraph now exists, but it is, as described, a dependency tree. There is still no information about multiple packages depending on a single earlier one. The dependency graph isn't a tree when the same package appears multiple times, and I know portage/equery does something to handle this to make sure all >= and <= requirements of all packages are simultaneously met. Let me try to motivate the requirement: Say the gcc team (which I am not part of) wanted to make sure that a particular set of core packages (toolchain, apache, apache2, tcl, ruby, xorg, kde, gnome, for example) built correctly with a proposed patch and a particular set of USE flags, and had a large group of Gentoo systems (perhaps chrooted) at their disposal to run this test. The best way to do this test would be to first issue one system package to each host to rebuild and make binary packages that are then merged to all hosts. Then each host is using an identical toolchain of the version needing to be tested. Now the entire set of test packages needs to be built, probably including rebuilding the toolchain using the new compiler version. It then becomes important to identify all the packages that depend on say libXt, in order to schedule them correctly. This would be much more powerful than distcc because (1) parallelism considering independent packages is much higher than parallelism in a single package and (2) configure scripts would be run in parallel as well. (In reply to comment #2) > There is still no information about multiple packages depending on a single > earlier one. The dependency graph isn't a tree when the same package appears > multiple times, and I know portage/equery does something to handle this to make > sure all >= and <= requirements of all packages are simultaneously met. All that I know about equery's depgraph is that it doesn't work correctly. Until very recently, portage (emerge) has always built an incomplete depgraph. The currently latest version of portage (2.1.2_pre2-r3) is the first release that's ever been able to build a complete depgraph and handle circular RDEPEND correctly. If you're interested in analysis of dependencies in the portage tree, you may also want to look at two competing projects: paludis and pkgcore. As far as I know, both of those expose everything that you will need as libraries (paludis is C++ and pkcore is python). equery's depends and depgraph functions are broken. For users just looking for more accurate dependency information, I am recommending app-portage/udept I do plan on completely rewriting the depends and depgraph functionality, but work is interfering at the moment with tackling that size of a change. In the meantime, if anyone wants to hack/work on the gentoolkit modules, the source is available at http://viewcvs.gentoo.org/viewcvs.py/gentoolkit/trunk/src/gentoolkit/ I will gratefully review any new bugs from people hacking on those modules. emerge's depgraph code would have to be nearing a stage where it can be split out into portage_dep or the like, no? (In reply to comment #5) > emerge's depgraph code would have to be nearing a stage where it can be split > out into portage_dep or the like, no? When we expose the depgraph in the api, we'll be stuck with maintaining backward compatibility. We may want to look into solving things like bug 1343 and bug 141118 before we expose it. *** This bug has been marked as a duplicate of bug 136932 *** |