Peter Stuge <pe...@stuge.se> wrote:
> 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.
Alternatively (if no conflict arises), foo depends forever on an
ancient (hence possibly full of security bugs) version of bar
which should have been upgraded ages ago.
In both cases of 6., the user is not even aware that he uses
long obsolete packages unless portage prints a big fat warning
for orphaned packages (which currently is not the case.
Well, at least eix -t will be print a message.)
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...)
