Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: We need *you* for a USE="selinux" dependency
Date: Mon, 05 Dec 2011 07:28:47
Message-Id: pan.2011.12.05.07.27.14@cox.net
In Reply to: Re: [gentoo-dev] We need *you* for a USE="selinux" dependency by Rich Freeman
1 Rich Freeman posted on Sun, 04 Dec 2011 22:10:19 -0500 as excerpted:
2
3 > My sense is that none of the PMS versions really say quite what we want
4 > the behavior to be - as to be truly compliant ebuilds would have to
5 > require nothing outside of the base system in the pkg phases (other than
6 > pkg_config) - then again, maybe we can live with that. It doesn't seem
7 > to add much value to say that RDEPEND /might/ be available - the
8 > necessary conditional logic to take advantage of a command that might or
9 > might not be present seems like a QA nightmare. We should probably
10 > specify that ebuilds either can safely count on RDEPEND, or not, in each
11 > of the phases.
12
13 tl;dr folks can skip. This is just an explanation for those who might
14 need it, tho the usual disclaimers about not being a PM or PMS guru
15 apply, so assuming I've got it straight, myself.
16
17 You are, I believe, correct as to the pkg phase requirements -- other
18 than pkg_config, they actually require nothing other than @system. The
19 second-to-last paragraph has the solution already proposed by the PM/PMS
20 folks, but there's some resistance, reasons explained there.
21
22 It helps to keep in mind the situation with 100% binpkg installations
23 that do no building, along with RDEPEND's cycle-breaking role. Obviously
24 DEPEND can't be counted on there since such systems do no building.
25 Equally obviously, RDEPEND must eventually be installed for full runtime
26 functionality, but can't be depended on during the pkg phases so as to
27 fill the circular dependency requirements.
28
29 The distinction between PDEPEND and RDEPEND, then, is that PDEPEND is
30 more like a strong recommendation, it should be installed as well, but
31 the package doesn't depend on it to actually run so installation can be
32 put off more or less indefinitely, while RDEPEND is assumed to be there
33 as soon as the package is installed, since at that point it's assumed to
34 be runnable and RDEPEND is runtime dependencies. So RDEPEND can't be
35 depended upon during installation (both src and pkg phases, other than
36 pkg_config but like PDEPEND, that can be put off indefinitely, from the
37 PM's and thus PMS perspective), but IS depended upon IMMEDIATELY AFTER
38 installation, as the package is then considered runnable and thus RDEPEND
39 must be installed, while PDEPEND installation can be put off effectively
40 indefinitely.
41
42 In practice, because a package is assumed to be runnable as soon as it is
43 fully installed, RDEPEND is NORMALLY installed first and thus there for
44 most or all phases, as that's the easiest way to ensure that the package
45 is fully runnable after the PM is done with that package, but that's not
46 REQUIRED to be the case, and in a circular dependency bind, a PM MAY have
47 to wait until after all installation phases are complete, then pause
48 before actually certifying it so and install the RDEPEND then.
49
50 As a paused install, the PM can then fudge the dependencies of the
51 circularly dependent package since the paused install /is/ actually
52 installed, all installation phases complete, it's just waiting on that
53 circular dependency RDEPEND to take the installation off pause and
54 certify it as fully installed.
55
56 For build-systems, putting a package in both DEPEND and RDEPEND thus in
57 practice assures that it's installed during pkg_preinst and pkg_postinst,
58 since the PM isn't likely to install it for building, then uninstall it,
59 then ensure that it's installed after installation at runtime again, but
60 that doesn't work on 100% binpkg installations either, since they don't
61 have to consider DEPEND at all because the package isn't being built.
62
63 This corner-case is why Ciaran and others involved with the PMs and PMS
64 have recommended adding additional dependency types, among them, one that
65 would be required during the post-build install phases (pkg_preinst and
66 pkg_postinst). That recommendation hasn't gone anywhere, however,
67 because in most cases the existing deps are "good enough", and at some
68 point, there's simply too many *DEPEND types to effectively keep track
69 of, such that the additional costs aren't considered worth the trouble of
70 the corner-case solution.
71
72 I suppose that corner-case might be one reason I occasionally have
73 installation failures on big updates such as kde, but with --keep-going,
74 portage continues to install other packages, and at some point manually
75 retrying the failed installation "just works". The other reason (other
76 than the occasional job token miscount, -j* issue when multiple merges
77 are going on, or other apparently random build-system failure) is of
78 course incompletely specified deps in the dependency thicket of upstream
79 kde's monolithic tarball buildsystem, but I can't fault gentoo/kde for
80 missing something there occasionally, particularly when it's not
81 reproducible afterward because the ordering has been resolved!
82
83 --
84 Duncan - List replies preferred. No HTML msgs.
85 "Every nonfree program has a lord, a master --
86 and if you use the program, he is your master." Richard Stallman