Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Duncan <1i5t5.duncan@...>
Subject: Re: We need *you* for a USE="selinux" dependency
Date: Mon, 5 Dec 2011 07:27:15 +0000 (UTC)
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



References:
We need *you* for a USE="selinux" dependency
-- Sven Vermeulen
Re: We need *you* for a USE="selinux" dependency
-- Fabio Erculiani
Re: We need *you* for a USE="selinux" dependency
-- Rich Freeman
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: We need *you* for a USE="selinux" dependency
Next by thread:
Re: We need *you* for a USE="selinux" dependency
Previous by date:
sources.gentoo.org instability
Next by date:
Re: We need *you* for a USE="selinux" dependency


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.