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