1 |
On Wed, Sep 19, 2012 at 12:53:09AM +0200, Micha?? G??rny wrote: |
2 |
> On Tue, 18 Sep 2012 23:06:19 +0100 |
3 |
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
4 |
> |
5 |
> > On Wed, 19 Sep 2012 00:01:21 +0200 |
6 |
> > Micha?? G??rny <mgorny@g.o> wrote: |
7 |
> > > On Tue, 18 Sep 2012 22:37:19 +0100 |
8 |
> > > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
9 |
> > > > On Tue, 18 Sep 2012 23:34:29 +0200 |
10 |
> > > > Micha?? G??rny <mgorny@g.o> wrote: |
11 |
> > > > > On Tue, 18 Sep 2012 22:08:43 +0100 |
12 |
> > > > > Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> wrote: |
13 |
> > > > > > On Tue, 18 Sep 2012 23:06:06 +0200 |
14 |
> > > > > > Micha?? G??rny <mgorny@g.o> wrote: |
15 |
> > > > > > > But didn't we already point out that we can't have them in |
16 |
> > > > > > > RDEPEND since they introduce conflicts? |
17 |
> > > > > > |
18 |
> > > > > > You are missing a basic and important part of how dependency |
19 |
> > > > > > resolution works: currently, cycles consisting purely of |
20 |
> > > > > > RDEPENDs are ignorable. |
21 |
> > > > > |
22 |
> > > > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe |
23 |
> > > > > that we actually gain RDEPs which can be actually trusted. |
24 |
> > > > |
25 |
> > > > "ASAP" is a weaker guarantee that RDEPENDs currently have -- |
26 |
> > > > RDEPENDs currently have the weakest guarantee necessary to ensure |
27 |
> > > > that they can be trusted. It's also a useless guarantee, since |
28 |
> > > > "ASAP" can be arbitrarily late. |
29 |
> > > |
30 |
> > > And can't RDEPENDs be arbitrarily late if there is a cycle? |
31 |
> > |
32 |
> > No. RDEPENDs have to be available when a package is used to satisfy a |
33 |
> > dependency. That's the difference between an RDEPEND and a PDEPEND. |
34 |
> |
35 |
> So, if a particular cycle prohibits RDEPENDs being fulfilled when |
36 |
> RDEPEND is needed to satisfy a dependency, we have a failure now, |
37 |
> correct? |
38 |
|
39 |
Depends on the cycle, but yes. |
40 |
|
41 |
Order of depdencies for this converation; depends is strongest, |
42 |
rdepends is second, pdepend is weak. If a pkg both deps and rdeps on |
43 |
something, for building (since that's the first op), dep obviously |
44 |
trumps all other dep forms for that pkg. |
45 |
|
46 |
pkg1 depends <-> pkg2 depends cycle, we're boned, unsolvable; use dep |
47 |
toggling at best. |
48 |
|
49 |
pkg1 rdepends -> pkg2, pkg2 depends on pkg1, strictly speaking, we're |
50 |
boned; pkg1 isn't considered 'usable' until pkg2 is considered |
51 |
'usable'. This is the common case where use pdepend instead of rdep. |
52 |
|
53 |
pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is |
54 |
mergable. |
55 |
|
56 |
Now if for pkg1 rdep<->pkg2 rdep, pkg2 rdeps on pkg3 (which neds to |
57 |
be built), which deps on pkg1 this too, is an unsolvable chain. |
58 |
|
59 |
you can build pkg1 and pkg2, and even install them. But pkg3 cannot |
60 |
be built until pkg1 is considered 'usable', which can't be be |
61 |
considered usable till pkg2 is considered usable, which (take a guess |
62 |
where I'm going with this) can't be considered usable until pkg3 is |
63 |
considered usable. |
64 |
|
65 |
|
66 |
> Do we have that guarantee somewhere in the PMS? |
67 |
|
68 |
It's not too hard to check in the doc yourself, ya know. ;) |
69 |
|
70 |
relevant latex chunk: |
71 |
""" |
72 |
\begin{compactitem} |
73 |
|
74 |
\item Build dependencies (\t{DEPEND}). These must be installed and |
75 |
usable before any of the ebuild \t{src\_*} phase functions is |
76 |
executed. These may not be installed at all if a binary package is |
77 |
being merged. |
78 |
|
79 |
\item Runtime dependencies (\t{RDEPEND}). These must be installed and |
80 |
usable befor the results of an ebuild merging are treated as usable. |
81 |
|
82 |
\item Post dependencies (\t{PDEPEND}). These must be installed at some |
83 |
point before the package manager finishes the batch of installs. |
84 |
\end{compactitem} |
85 |
""" |
86 |
|
87 |
keyword there is 'usable'. Wording could be expanded, but the core |
88 |
notion is there- it just skips going over graph theory/resolver |
89 |
guts/cycles since they're not explicitly a property of dependecy |
90 |
types. |
91 |
|
92 |
Feel free to write a patch expanding the wording htere... |
93 |
|
94 |
~harring |