Re: [gentoo-dev] New PDEPEND behaviour.

[Carsten Lohrke <carlo@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

On Mittwoch, 25. Juli 2007, Brian Harring wrote:
> 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

Uh, thanks, I never was fond of reading the code of Portage, so I took Piotr's 
point as given.

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

That's fine.

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

Well, I should point out where I come from. There is no need to install a pure 
runtime dependency before the ebuild pulling it in. If pure runtime 
dependencies would be handled this way, there would be no need for PDEPEND at 
all. I consider the current way Portage handles pure runtime dependencies 
(causing the need for the artificial PDEPEND in the first place) as 
conceptually broken.


Carsten

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]