Martin Vaeth wrote:
> >> > The user's vardb could then automatically receive the last state of
> >> > the ebuild, before it was removed.
> >>
> >> It doesn't help reliably, either, since the last state of the ebuild,
> >> before it was removed, will be outdated at some point, too.
> >
> > Sorry, I don't see how. Can you give an example? Thanks!
>
> 1. foo depends on bar
> 2. user installs foo
> 3. foo is treecleaned
> 4. bar ebuild is replaced by the pair bar-base and bar-gui to
> allow for finer dependency. All ebuilds in the tree take
> care about this new structure (possibly with revbumps).
> Of course, the dependency for an already removed package
> is not fixed.
> 5. bar{-base,gui} gets several upgrades.
> 6. foo on user's system still blocks bar from being removed
> and thus blocks the installation of bar-base and bar-gui
> forever.
Thanks for spelling it out!
This suggests another data model bug to me: that dependencies belong
to the dependent packages, rather than to dependency providers.
What I mean is that in the above example, bar "knows" that bar has
turned into bar-{base,gui}, but foo doesn't.
> Note that 4. cannot be replaced by any "pushing" mechanism,
> since only the maintainer of the ebuild can know which is
> the "right" dependency for the new tree structure. Such a
> maintainer does not exist for treecleaned packages (which
> is the purpose of treecleaning, after all...)
If the user updates their package database things would still work
if 4 modifies the effective dependencies for foo to reflect the new
reality of bar -> bar-{base,gui}.
foo is not being maintained, but bar is. It might be incorrect to say
that foo depends on both bar-base and -gui (foo might just need -base)
but it is perfectly safe to automatically make the most pessimistic
assumption when upgrading the outdated dependency on bar in all
installed-but-outdated-ebuilds.
The code required for this would even allow to partially automate
dependency changes like bar -> bar-{base,gui} across the tree.
Maintainers could get notified when a package they depend on change,
and the safe default is to just roll along. Less dev work! \o/
The more I think about dependencies the more convinced I am that
dependency information must be versioned, ie. dependencies only
matter in the context of the particular package database snapshot
they came from, and that installed dependencies must be kept up to
date as the package database evolves.
Otherwise there's just a pile of heuristics, which throw people,
which I guess is why dynamic-deps cause problems and ire.
Rich Freeman wrote:
> This is really the crux of these sorts of issues. It doesn't matter
> if dependencies are static or dynamic - if you hang onto orphans then
> you're going to have cruft in your vdb which is going to lead to
> blockers of some kind eventually.
I think the vdb can and should be updated according to portage changes.
Someone just needs to code it. ;)
//Peter
