| 1 |
On Mittwoch, 25. Juli 2007, Brian Harring wrote: |
| 2 |
> I suggest you in the future check out what actually was changed, and |
| 3 |
> do some testing- both the original poster, and yourself are missing |
| 4 |
> what is occuring here |
| 5 |
|
| 6 |
Uh, thanks, I never was fond of reading the code of Portage, so I took Piotr's |
| 7 |
point as given. |
| 8 |
|
| 9 |
> Note I said 'shift'. It tries to place it earlier in the graph, while |
| 10 |
> *still* maintaining the constraints of kdnssd-avahi- namely the |
| 11 |
> kdelibs dependency. |
| 12 |
> |
| 13 |
> Via that dep, kdnssd-avahi *requires* kdelibs to be installed first, |
| 14 |
> and portage honors that- it just now tries to get kdnssd-avahi merged |
| 15 |
> as soon as possible after kdelibs due to their PDEPEND relationship |
| 16 |
> (try it if in doubt, it lineralizes it properly). |
| 17 |
> |
| 18 |
> The cases where it doesn't, are when the constraints are already |
| 19 |
> satisfied- kdelibs already is merged, basically. There is a change in |
| 20 |
> placement there, but considering the data involved, wouldn't label it |
| 21 |
> a regression- same issue can, and does occur in multiple other ways. |
| 22 |
|
| 23 |
That's fine. |
| 24 |
|
| 25 |
> > The latter. |
| 26 |
> |
| 27 |
> Former. The ebuild manpage is a bit loose in it's description of what |
| 28 |
> PDEPEND does. |
| 29 |
|
| 30 |
Well, I should point out where I come from. There is no need to install a pure |
| 31 |
runtime dependency before the ebuild pulling it in. If pure runtime |
| 32 |
dependencies would be handled this way, there would be no need for PDEPEND at |
| 33 |
all. I consider the current way Portage handles pure runtime dependencies |
| 34 |
(causing the need for the artificial PDEPEND in the first place) as |
| 35 |
conceptually broken. |
| 36 |
|
| 37 |
|
| 38 |
Carsten |
Archives