| 1 |
Martin Vaeth wrote: |
| 2 |
> >> > The user's vardb could then automatically receive the last state of |
| 3 |
> >> > the ebuild, before it was removed. |
| 4 |
> >> |
| 5 |
> >> It doesn't help reliably, either, since the last state of the ebuild, |
| 6 |
> >> before it was removed, will be outdated at some point, too. |
| 7 |
> > |
| 8 |
> > Sorry, I don't see how. Can you give an example? Thanks! |
| 9 |
> |
| 10 |
> 1. foo depends on bar |
| 11 |
> 2. user installs foo |
| 12 |
> 3. foo is treecleaned |
| 13 |
> 4. bar ebuild is replaced by the pair bar-base and bar-gui to |
| 14 |
> allow for finer dependency. All ebuilds in the tree take |
| 15 |
> care about this new structure (possibly with revbumps). |
| 16 |
> Of course, the dependency for an already removed package |
| 17 |
> is not fixed. |
| 18 |
> 5. bar{-base,gui} gets several upgrades. |
| 19 |
> 6. foo on user's system still blocks bar from being removed |
| 20 |
> and thus blocks the installation of bar-base and bar-gui |
| 21 |
> forever. |
| 22 |
|
| 23 |
Thanks for spelling it out! |
| 24 |
|
| 25 |
This suggests another data model bug to me: that dependencies belong |
| 26 |
to the dependent packages, rather than to dependency providers. |
| 27 |
|
| 28 |
What I mean is that in the above example, bar "knows" that bar has |
| 29 |
turned into bar-{base,gui}, but foo doesn't. |
| 30 |
|
| 31 |
|
| 32 |
> Note that 4. cannot be replaced by any "pushing" mechanism, |
| 33 |
> since only the maintainer of the ebuild can know which is |
| 34 |
> the "right" dependency for the new tree structure. Such a |
| 35 |
> maintainer does not exist for treecleaned packages (which |
| 36 |
> is the purpose of treecleaning, after all...) |
| 37 |
|
| 38 |
If the user updates their package database things would still work |
| 39 |
if 4 modifies the effective dependencies for foo to reflect the new |
| 40 |
reality of bar -> bar-{base,gui}. |
| 41 |
|
| 42 |
foo is not being maintained, but bar is. It might be incorrect to say |
| 43 |
that foo depends on both bar-base and -gui (foo might just need -base) |
| 44 |
but it is perfectly safe to automatically make the most pessimistic |
| 45 |
assumption when upgrading the outdated dependency on bar in all |
| 46 |
installed-but-outdated-ebuilds. |
| 47 |
|
| 48 |
The code required for this would even allow to partially automate |
| 49 |
dependency changes like bar -> bar-{base,gui} across the tree. |
| 50 |
Maintainers could get notified when a package they depend on change, |
| 51 |
and the safe default is to just roll along. Less dev work! \o/ |
| 52 |
|
| 53 |
|
| 54 |
The more I think about dependencies the more convinced I am that |
| 55 |
dependency information must be versioned, ie. dependencies only |
| 56 |
matter in the context of the particular package database snapshot |
| 57 |
they came from, and that installed dependencies must be kept up to |
| 58 |
date as the package database evolves. |
| 59 |
|
| 60 |
Otherwise there's just a pile of heuristics, which throw people, |
| 61 |
which I guess is why dynamic-deps cause problems and ire. |
| 62 |
|
| 63 |
|
| 64 |
Rich Freeman wrote: |
| 65 |
> This is really the crux of these sorts of issues. It doesn't matter |
| 66 |
> if dependencies are static or dynamic - if you hang onto orphans then |
| 67 |
> you're going to have cruft in your vdb which is going to lead to |
| 68 |
> blockers of some kind eventually. |
| 69 |
|
| 70 |
I think the vdb can and should be updated according to portage changes. |
| 71 |
|
| 72 |
Someone just needs to code it. ;) |
| 73 |
|
| 74 |
|
| 75 |
//Peter |
Archives