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
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