Rich Freeman posted on Sun, 04 Dec 2011 22:10:19 -0500 as excerpted: > My sense is that none of the PMS versions really say quite what we want > the behavior to be - as to be truly compliant ebuilds would have to > require nothing outside of the base system in the pkg phases (other than > pkg_config) - then again, maybe we can live with that. It doesn't seem > to add much value to say that RDEPEND /might/ be available - the > necessary conditional logic to take advantage of a command that might or > might not be present seems like a QA nightmare. We should probably > specify that ebuilds either can safely count on RDEPEND, or not, in each > of the phases.
tl;dr folks can skip. This is just an explanation for those who might need it, tho the usual disclaimers about not being a PM or PMS guru apply, so assuming I've got it straight, myself. You are, I believe, correct as to the pkg phase requirements -- other than pkg_config, they actually require nothing other than @system. The second-to-last paragraph has the solution already proposed by the PM/PMS folks, but there's some resistance, reasons explained there. It helps to keep in mind the situation with 100% binpkg installations that do no building, along with RDEPEND's cycle-breaking role. Obviously DEPEND can't be counted on there since such systems do no building. Equally obviously, RDEPEND must eventually be installed for full runtime functionality, but can't be depended on during the pkg phases so as to fill the circular dependency requirements. The distinction between PDEPEND and RDEPEND, then, is that PDEPEND is more like a strong recommendation, it should be installed as well, but the package doesn't depend on it to actually run so installation can be put off more or less indefinitely, while RDEPEND is assumed to be there as soon as the package is installed, since at that point it's assumed to be runnable and RDEPEND is runtime dependencies. So RDEPEND can't be depended upon during installation (both src and pkg phases, other than pkg_config but like PDEPEND, that can be put off indefinitely, from the PM's and thus PMS perspective), but IS depended upon IMMEDIATELY AFTER installation, as the package is then considered runnable and thus RDEPEND must be installed, while PDEPEND installation can be put off effectively indefinitely. In practice, because a package is assumed to be runnable as soon as it is fully installed, RDEPEND is NORMALLY installed first and thus there for most or all phases, as that's the easiest way to ensure that the package is fully runnable after the PM is done with that package, but that's not REQUIRED to be the case, and in a circular dependency bind, a PM MAY have to wait until after all installation phases are complete, then pause before actually certifying it so and install the RDEPEND then. As a paused install, the PM can then fudge the dependencies of the circularly dependent package since the paused install /is/ actually installed, all installation phases complete, it's just waiting on that circular dependency RDEPEND to take the installation off pause and certify it as fully installed. For build-systems, putting a package in both DEPEND and RDEPEND thus in practice assures that it's installed during pkg_preinst and pkg_postinst, since the PM isn't likely to install it for building, then uninstall it, then ensure that it's installed after installation at runtime again, but that doesn't work on 100% binpkg installations either, since they don't have to consider DEPEND at all because the package isn't being built. This corner-case is why Ciaran and others involved with the PMs and PMS have recommended adding additional dependency types, among them, one that would be required during the post-build install phases (pkg_preinst and pkg_postinst). That recommendation hasn't gone anywhere, however, because in most cases the existing deps are "good enough", and at some point, there's simply too many *DEPEND types to effectively keep track of, such that the additional costs aren't considered worth the trouble of the corner-case solution. I suppose that corner-case might be one reason I occasionally have installation failures on big updates such as kde, but with --keep-going, portage continues to install other packages, and at some point manually retrying the failed installation "just works". The other reason (other than the occasional job token miscount, -j* issue when multiple merges are going on, or other apparently random build-system failure) is of course incompletely specified deps in the dependency thicket of upstream kde's monolithic tarball buildsystem, but I can't fault gentoo/kde for missing something there occasionally, particularly when it's not reproducible afterward because the ordering has been resolved! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
