List Archive: gentoo-dev
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Sun, Dec 4, 2011 at 5:10 PM, Fabio Erculiani <firstname.lastname@example.org> wrote:
> I haven't really understood what you mean with RDEPENDs being scheduled "after".
> RDEPEND must be always scheduled before the pkg requiring it, changing
> this behaviour would have disruptive effects on all the PMS out there
There is only one PMS out there, unless you're counting versions (they
are cumulative so the latest approved one should be the one you use -
correct me if I'm wrong there). PMS != package manager.
In this particular case the approved PMS says "In the pkg phases, at
least one of the following conditions must be met: any command
provided by a packaged listed in DEPEND is available; any command
provided by a packaged listed in RDEPEND is available." Perhaps
somebody with a more twisted sense of logic than I can make some sense
out of that - to me it suggests that an ebuild can safely assume that
either the packages listed in DEPEND are available, or the packages
listed in RDEPEND are available, but not necessarily both (though you
could count on RDEPEND if you have DEPEND=RDEPEND set or are using an
EAPI that has this behavior).
I suspect that the PMS team has already noticed that since the current
non-approved PMS is a bit more clear. It says (in a table) that any
of the pkg phases can assume that the RDEPENDs are there "(unless the
particular dependency results in a circular dependency, in which case
it may be installed later)." I guess that means that pkg phases can't
assume that RDEPENDs are there after all. Additionally pkg_config can
assume that RDEPEND and PDEPEND are present (with no caveats). None
of the pkg phases can assume that anything in DEPEND is present
(obviously unless it is also in RDEPEND).
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.
(Disclaimer - I claim no special knowledge of the mechanics of your
favorite package manager - I'm simply reading the specs.)