1 |
On Mon, 15 Aug 2011 09:43:52 +0200 |
2 |
Ulrich Mueller <ulm@g.o> wrote: |
3 |
> Hm, I always thought that e.g. for packages that have no reverse |
4 |
> dependencies the issue would not arise. For example, if you have the |
5 |
> following RDEPEND cycle: |
6 |
> |
7 |
> C ← D ← E |
8 |
> ↓ ↑ |
9 |
> B → A |
10 |
> |
11 |
> then the ordering of A, B, C and D would be unspecified, but it would |
12 |
> be guaranteed that package E (which is not part of the cycle) is being |
13 |
> installed last. |
14 |
|
15 |
Nope. If you've just got RDEPENDs, there's no guarantee of any order at |
16 |
all. If you had this: |
17 |
|
18 |
C ← D ← E <=== F |
19 |
↓ ↑ |
20 |
B → A |
21 |
|
22 |
where F's dep is a DEPEND (and where F is not a binary package), then |
23 |
you're guaranteed that all of A, B, C, D and E will be merged before F, |
24 |
but you don't get any guarantee as to the order amongst A, B, C, D, E. |
25 |
|
26 |
Introducing a stronger guarantee wouldn't even help: here, the |
27 |
maintainer of E could carefully check that there is no possible cycle |
28 |
containing both D and E, making it safe to use D in pkg_setup, and then |
29 |
the next week A's maintainer (or worse, an overlay) could come along and |
30 |
make A RDEPEND upon E. Then E's carefully checked pkg_setup would |
31 |
suddenly become broken through something unrelated to either E or its |
32 |
direct dependencies, and there would be no way to know about it until |
33 |
people get hit by weird bugs. |
34 |
|
35 |
The only fix is to tell people they must write pkg_* code to carry on |
36 |
working if dependencies aren't present, and then to introduce IDEPEND |
37 |
(or the equivalent label) in EAPI 5. |
38 |
|
39 |
-- |
40 |
Ciaran McCreesh |