Bug#477166: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5
On Mon, Apr 21, 2008 at 03:59:26PM +0200, Sven Joachim <svenjoac@gmx.de> was heard to say:
> Some time ago, python-elementtree was pulled in as a recommendation of
> translate-toolkit. The situation is as this:
>
> ,----
> | $ aptitude show python-elementtree | grep ^Auto
> | Automatically installed: yes
> | $ aptitude why python-elementtree
> | i translate-toolkit Recommends python (>= 2.5) | python-elementtree
> `----
As you can see, python-elementtree is depended upon by translate-toolkit.
aptitude will not autoremove packages that another package depends on,
and it won't try to guess which branch of a dependency you don't want --
that requires a brain, and we're all out of those over here. :-)
You noted that I should remove python-elementtree because only
translate-toolkit requires it. But what about this?
package-with-images Recommends bad-but-small-viewer | big-but-good-viewer
Say I install big-but-good-viewer automatically (for whatever reason:
via dependency resolution, by marking it automatic by hand, or because
it was the only option at the time). Then bad-but-small-viewer becomes
available and is added as a dep, plus something else depends on it and
drags it in.
Should aptitude remove big-but-good-viewer? If so, I guarantee its
users will file bugs. :-) If not, then why should aptitude know it can
remove python-elementtree above? Without human-level intelligence and
contextual understanding, how can the program distinguish between these
cases? Right now the dependency resolver operates on package dependency
graphs and doesn't have sentience. or knowledge of the difference
between an image viewer and a programming language library.
The autoremoval stuff is designed to be conservative in what it
removes: it only removes packages if it can prove that nothing depends
on them. This sometimes results in oddities like the above, but those
are much better than the alternative. *Even if* a complicated algorithm
existed to decide what should be removed (and as I noted above, I don't
believe any such algorithm exists because the package that should be
removed is not a function of the inputs to the dependency resolver), I
think the grounds of simplicity and comprehensibility argue in favor of
aptitude's current behavior. When it misbehaves, you can understand why
without reading an AI textbook first. :)
Since people file this bug occasionally, I'll leave it open and mark
it "wontfix". Also, since this logic is now located in apt rather than
aptitude, I'll reassign it over there. (Michael and Otavio: feel free
to untag this if you disagree with me)
Daniel
Reply to: