Re: [gentoo-dev] New PDEPEND behaviour.

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1761 bytes --]

On Wed, Jul 25, 2007 at 02:08:39PM +0200, Piotr Jaroszy??ski wrote:
> Hello,
> 
> As a result of bug #180045 PDEPENDs can be now merged even before the package 
> that pulls them. Zmedico says that's intended behaviour and PDEPEND is really 
> a RDEPEND, but with a ability to resolve circular deps:
> circular DEPEND <-> RDEPEND can't be resolved while circular DEPEND <-> 
> PDEPEND can.
> Random behaviour occurs when there is a circular RDEPEND <-> PDEPEND, e.g. bug 
> #186517.
> 
> We need to update docs or harass zmedico to force PDEPEND to be pulled as soon 
> as possible but not before the pkg that pulls it.

PDEPEND (just like RDEPEND), can, and always has been *able* to be 
satisfied prior to the node that requires it- the name may suck, but 
it's better then BREAK_RDEPEND_CYCLES, thus PDEPEND; it's never been 
viewed as a literal "it must be post" however.  Semi curious when the 
ebuild manpage picked up that description also- would expect its just 
a bad choice of words.

If in doubt, suggest you do some experiments with earlier portage 
versions, explicitly trying to force a node that is PDEPEND'd upon to 
come prior- ought to occur fine.  Basically, you're arguing based upon 
*most* PDEPEND'd nodes dep'ing on the original PDEPENDer (a cycle, 
thus with PDEPEND breaking it, the PDEPEND target coming first due to 
resolution rules) - not on rules of PDEPEND.

Either way, proposing that PDEPEND (a cycle breaking RDEPEND), be 
literal post is likely going trigger some fun fallout with the 
existing consumers of it.  Suggest you investigate those before 
pushing this idea further.

On the offchance there isn't nasty fallout from your proposal, still 
view it as -1 for the change.

~harring

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]