| 1 |
Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> |
| 3 |
> 1) Foo incorrectly deps on bar |
| 4 |
> 2) User installs foo with the incorrect dep |
| 5 |
> 3) Foo maintainer detects the error |
| 6 |
> 4) Due to dynamic-deps, portage depcleans bar. |
| 7 |
> 5) Since nothing in the tree needs bar, it is removed. |
| 8 |
> 6) Finally, foo is removed from tree. |
| 9 |
> |
| 10 |
> ** User isn't ready to get rid of foo yet, but user's dep-tree just blew |
| 11 |
> up |
| 12 |
|
| 13 |
This is the problem of orphaned (without maintained ebuilds) packages: |
| 14 |
Both, dynamic and static deps break on the similar situation for |
| 15 |
different reasons. |
| 16 |
|
| 17 |
The above describes one problem which you get in this case with |
| 18 |
dynamic deps; to get a similar problem with static deps, you need |
| 19 |
a slightly different situation: |
| 20 |
|
| 21 |
1-3 as above, 4 is skipped (due to static deps). |
| 22 |
5) bar is split into bar-base and bar-gui. |
| 23 |
6) as above (foo is removed from the tree). |
| 24 |
|
| 25 |
Now the static deps will keep in bar forever, omitting that the |
| 26 |
packages in the tree can install bar-base or bar-gui. |
| 27 |
The user's dep-tree blows up through blockers or merge conflict |
| 28 |
which cannot be resolved. |
| 29 |
|
| 30 |
I repeat once more: For packages no longer maintained in the tree, |
| 31 |
there is no secure way to treat them always correctly; |
| 32 |
"no longer maintained" means exactly this. |
| 33 |
|
| 34 |
Either the user should remove them, or he should take full |
| 35 |
responsibility by maintaining them by himself in his overlay. |
| 36 |
Choosing a strategy (dynamic or static deps) should not concentrate |
| 37 |
on users who refuse to choose this only reasonable solution - |
| 38 |
as excpected, they get a solution which works sometimes, but they |
| 39 |
have to keep the pieces when it breaks, no matter which strategy |
| 40 |
is decided. |
| 41 |
|
| 42 |
> What's worse, the usual trick of digging the ebuild out of vardb and |
| 43 |
> putting it in the user's overlay to shut portage up and let the user keep |
| 44 |
> foo doesn't work, because the vardb ebuild has an unsatisfied dep. |
| 45 |
|
| 46 |
This is not so bad: The user has to put a corrected ebuild into his |
| 47 |
overlay and must reemerge the package (currently, the latter could |
| 48 |
be skipped with dynamic deps). |
| 49 |
In fact, no matter whether you have static or dynamic deps, this is |
| 50 |
the only way to cleanly avoid the problems if you want to keep a |
| 51 |
package installed which is not maintained anymore: |
| 52 |
*You* must maintain it. There simply is no magic which can avoid this. |
Archives