1 |
On Wed, Jul 25, 2007 at 02:08:39PM +0200, Piotr Jaroszy??ski wrote: |
2 |
> Hello, |
3 |
> |
4 |
> As a result of bug #180045 PDEPENDs can be now merged even before the package |
5 |
> that pulls them. Zmedico says that's intended behaviour and PDEPEND is really |
6 |
> a RDEPEND, but with a ability to resolve circular deps: |
7 |
> circular DEPEND <-> RDEPEND can't be resolved while circular DEPEND <-> |
8 |
> PDEPEND can. |
9 |
> Random behaviour occurs when there is a circular RDEPEND <-> PDEPEND, e.g. bug |
10 |
> #186517. |
11 |
> |
12 |
> We need to update docs or harass zmedico to force PDEPEND to be pulled as soon |
13 |
> as possible but not before the pkg that pulls it. |
14 |
|
15 |
PDEPEND (just like RDEPEND), can, and always has been *able* to be |
16 |
satisfied prior to the node that requires it- the name may suck, but |
17 |
it's better then BREAK_RDEPEND_CYCLES, thus PDEPEND; it's never been |
18 |
viewed as a literal "it must be post" however. Semi curious when the |
19 |
ebuild manpage picked up that description also- would expect its just |
20 |
a bad choice of words. |
21 |
|
22 |
If in doubt, suggest you do some experiments with earlier portage |
23 |
versions, explicitly trying to force a node that is PDEPEND'd upon to |
24 |
come prior- ought to occur fine. Basically, you're arguing based upon |
25 |
*most* PDEPEND'd nodes dep'ing on the original PDEPENDer (a cycle, |
26 |
thus with PDEPEND breaking it, the PDEPEND target coming first due to |
27 |
resolution rules) - not on rules of PDEPEND. |
28 |
|
29 |
Either way, proposing that PDEPEND (a cycle breaking RDEPEND), be |
30 |
literal post is likely going trigger some fun fallout with the |
31 |
existing consumers of it. Suggest you investigate those before |
32 |
pushing this idea further. |
33 |
|
34 |
On the offchance there isn't nasty fallout from your proposal, still |
35 |
view it as -1 for the change. |
36 |
|
37 |
~harring |