On Wed, Jul 25, 2007 at 02:51:55PM +0200, Carsten Lohrke wrote:
> On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote:
> > As a result of bug #180045 PDEPENDs can be now merged even before the
> > package that pulls them. Zmedico says that's intended behaviour
> 
> Well, then what our Portage devs think the intended behaviour should be is a 
> bug. E.g. in the case the bug refers to, we rely on Portage building  
> kdnssd-avahi after kdelibs (otherwise it simply would fail), but before any 
> other ebuild that might need kdnssd-avahi.

I suggest you in the future check out what actually was changed, and 
do some testing- both the original poster, and yourself are missing 
what is occuring here (if it's any consolation, I missed the real 
cause of 186517 initially too :).  The portage change is to shift the 
placement of PDEPENDed nodes as early as possible- specifically to 
fix cases where deps are a bit screwed up (like 180045, 
kdnssd-avahi/kdelibs).

Note I said 'shift'.  It tries to place it earlier in the graph, while 
*still* maintaining the constraints of kdnssd-avahi- namely the 
kdelibs dependency.

Via that dep, kdnssd-avahi *requires* kdelibs to be installed first, 
and portage honors that- it just now tries to get kdnssd-avahi merged 
as soon as possible after kdelibs due to their PDEPEND relationship 
(try it if in doubt, it lineralizes it properly).

The cases where it doesn't, are when the constraints are already 
satisfied- kdelibs already is merged, basically.  There is a change in 
placement there, but considering the data involved, wouldn't label it 
a regression- same issue can, and does occur in multiple other ways.


> And I'm pretty sure nearly 
> everyone using PDEPEND in his ebuilds relies on Portage building the PDEPEND 
> not before the ebuild, which lists it.

No one has relied on that in my experience.  They've relied on PDEPEND 
being satisfied, but not required to be satisfied by the time the 
PDEPENDer is considered 'satisfied' buildplan wise.

I strongly suspect folks echoing that sentiment are missing that a 
PDEPEND'ed nodes' DEPEND/RDEPEND *must* be satisfied prior to it being 
merged, and are missing what PDEPEND means to the resolver.


> > 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.
> 
> The latter.

Former.  The ebuild manpage is a bit loose in it's description of what 
PDEPEND does.

As cardoe commented, the flaw that folks are hitting in 186517 is a 
data flaw (the data is bad); it's not a flaw in the resolver 
behaviour.

Feed it bad data, it's going to do stupid things basically :)

~harring