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