| 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. |
| 10 |
|
| 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). |
| 18 |
|
| 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. |
| 22 |
|
| 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). |
| 27 |
|
| 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. |
| 32 |
|
| 33 |
|
| 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. |
| 37 |
|
| 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. |
| 41 |
|
| 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. |
| 45 |
|
| 46 |
|
| 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. |
| 51 |
|
| 52 |
Former. The ebuild manpage is a bit loose in it's description of what |
| 53 |
PDEPEND does. |
| 54 |
|
| 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. |
| 58 |
|
| 59 |
Feed it bad data, it's going to do stupid things basically :) |
| 60 |
|
| 61 |
~harring |
Archives