On Mon, Apr 21, 2008 at 03:59:26PM +0200, Sven Joachim <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
