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
signature.asc
Description: This is a digitally signed message part.
