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 |