[gentoo-dev] Re: don't rely on dynamic deps

[Martin Vaeth <martin@mvath.de>]

Duncan <1i5t5.duncan@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.