Gentoo Archives: gentoo-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] New PDEPEND behaviour.
Date: Wed, 25 Jul 2007 14:31:10
Message-Id: 20070725142509.GB17517@seldon
In Reply to: Re: [gentoo-dev] New PDEPEND behaviour. by Carsten Lohrke
1 On Wed, Jul 25, 2007 at 02:51:55PM +0200, Carsten Lohrke wrote:
2 > On Mittwoch, 25. Juli 2007, Piotr Jaroszyński wrote:
3 > > As a result of bug #180045 PDEPENDs can be now merged even before the
4 > > package that pulls them. Zmedico says that's intended behaviour
5 >
6 > Well, then what our Portage devs think the intended behaviour should be is a
7 > bug. E.g. in the case the bug refers to, we rely on Portage building
8 > kdnssd-avahi after kdelibs (otherwise it simply would fail), but before any
9 > other ebuild that might need kdnssd-avahi.
11 I suggest you in the future check out what actually was changed, and
12 do some testing- both the original poster, and yourself are missing
13 what is occuring here (if it's any consolation, I missed the real
14 cause of 186517 initially too :). The portage change is to shift the
15 placement of PDEPENDed nodes as early as possible- specifically to
16 fix cases where deps are a bit screwed up (like 180045,
17 kdnssd-avahi/kdelibs).
19 Note I said 'shift'. It tries to place it earlier in the graph, while
20 *still* maintaining the constraints of kdnssd-avahi- namely the
21 kdelibs dependency.
23 Via that dep, kdnssd-avahi *requires* kdelibs to be installed first,
24 and portage honors that- it just now tries to get kdnssd-avahi merged
25 as soon as possible after kdelibs due to their PDEPEND relationship
26 (try it if in doubt, it lineralizes it properly).
28 The cases where it doesn't, are when the constraints are already
29 satisfied- kdelibs already is merged, basically. There is a change in
30 placement there, but considering the data involved, wouldn't label it
31 a regression- same issue can, and does occur in multiple other ways.
34 > And I'm pretty sure nearly
35 > everyone using PDEPEND in his ebuilds relies on Portage building the PDEPEND
36 > not before the ebuild, which lists it.
38 No one has relied on that in my experience. They've relied on PDEPEND
39 being satisfied, but not required to be satisfied by the time the
40 PDEPENDer is considered 'satisfied' buildplan wise.
42 I strongly suspect folks echoing that sentiment are missing that a
43 PDEPEND'ed nodes' DEPEND/RDEPEND *must* be satisfied prior to it being
44 merged, and are missing what PDEPEND means to the resolver.
47 > > We need to update docs or harass zmedico to force PDEPEND to be pulled as
48 > > soon as possible but not before the pkg that pulls it.
49 >
50 > The latter.
52 Former. The ebuild manpage is a bit loose in it's description of what
53 PDEPEND does.
55 As cardoe commented, the flaw that folks are hitting in 186517 is a
56 data flaw (the data is bad); it's not a flaw in the resolver
57 behaviour.
59 Feed it bad data, it's going to do stupid things basically :)
61 ~harring


Subject Author
Re: [gentoo-dev] New PDEPEND behaviour. Carsten Lohrke <carlo@g.o>