| 1 |
Peter Stuge <peter@×××××.se> wrote: |
| 2 |
> Martin Vaeth wrote: |
| 3 |
>> > The user's vardb could then automatically receive the last state of |
| 4 |
>> > the ebuild, before it was removed. |
| 5 |
>> |
| 6 |
>> It doesn't help reliably, either, since the last state of the ebuild, |
| 7 |
>> before it was removed, will be outdated at some point, too. |
| 8 |
> |
| 9 |
> Sorry, I don't see how. Can you give an example? Thanks! |
| 10 |
|
| 11 |
1. foo depends on bar |
| 12 |
2. user installs foo |
| 13 |
3. foo is treecleaned |
| 14 |
4. bar ebuild is replaced by the pair bar-base and bar-gui to |
| 15 |
allow for finer dependency. All ebuilds in the tree take |
| 16 |
care about this new structure (possibly with revbumps). |
| 17 |
Of course, the dependency for an already removed package |
| 18 |
is not fixed. |
| 19 |
5. bar{-base,gui} gets several upgrades. |
| 20 |
6. foo on user's system still blocks bar from being removed |
| 21 |
and thus blocks the installation of bar-base and bar-gui |
| 22 |
forever. |
| 23 |
Alternatively (if no conflict arises), foo depends forever on an |
| 24 |
ancient (hence possibly full of security bugs) version of bar |
| 25 |
which should have been upgraded ages ago. |
| 26 |
|
| 27 |
In both cases of 6., the user is not even aware that he uses |
| 28 |
long obsolete packages unless portage prints a big fat warning |
| 29 |
for orphaned packages (which currently is not the case. |
| 30 |
Well, at least eix -t will be print a message.) |
| 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...) |
Archives