* Re: [gentoo-dev] New PDEPEND behaviour.
@ 2007-07-25 14:25 99% ` Brian Harring
0 siblings, 0 replies; 1+ results
From: Brian Harring @ 2007-07-25 14:25 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2007-07-25 12:08 [gentoo-dev] New PDEPEND behaviour Piotr Jaroszyński
2007-07-25 12:51 ` Carsten Lohrke
2007-07-25 14:25 99% ` Brian Harring
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox