On Mon, 15 Aug 2011 09:43:52 +0200
Ulrich Mueller <ulm@g.o> wrote:
> Hm, I always thought that e.g. for packages that have no reverse
> dependencies the issue would not arise. For example, if you have the
> following RDEPEND cycle:
> 
>     C ← D ← E
>     ↓   ↑
>     B → A
> 
> then the ordering of A, B, C and D would be unspecified, but it would
> be guaranteed that package E (which is not part of the cycle) is being
> installed last.

Nope. If you've just got RDEPENDs, there's no guarantee of any order at
all. If you had this:

     C ← D ← E <=== F
     ↓   ↑
     B → A

where F's dep is a DEPEND (and where F is not a binary package), then
you're guaranteed that all of A, B, C, D and E will be merged before F,
but you don't get any guarantee as to the order amongst A, B, C, D, E.

Introducing a stronger guarantee wouldn't even help: here, the
maintainer of E could carefully check that there is no possible cycle
containing both D and E, making it safe to use D in pkg_setup, and then
the next week A's maintainer (or worse, an overlay) could come along and
make A RDEPEND upon E. Then E's carefully checked pkg_setup would
suddenly become broken through something unrelated to either E or its
direct dependencies, and there would be no way to know about it until
people get hit by weird bugs.

The only fix is to tell people they must write pkg_* code to carry on
working if dependencies aren't present, and then to introduce IDEPEND
(or the equivalent label) in EAPI 5.

-- 
Ciaran McCreesh