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
pgpHZSvRJgHyO.pgp
Description: PGP signature
