Subject: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5
Date: Mon, 21 Apr 2008 15:59:26 +0200
Package: aptitude
Version: 0.4.11.2-1
Severity: normal
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
`----
By the time I first installed translate-toolkit, python was at 2.4, so
the "Recommends" could only be fulfilled by python-elementtree.
Meanwhile python got upgraded to 2.5, making python-elementtree
redundant; but aptitude does not seem to detect this. I should note
that
a) translate-toolkit is the only installed package depending on or
recommending python-elementtree;
b) python was not marked as automatically installed, but changing that
does not seem to have an effect.
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.24.5
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6. 0.7.11 Advanced front-end for dpkg
ii libc6 2.7-10 GNU C Library: Shared libraries
ii libcwidget3 0.5.11-1 high-level terminal interface libr
ii libept0 0.5.17 High-level library for managing De
ii libgcc1 1:4.3.0-3 GCC support library
ii libncursesw5 5.6+20080405-1 Shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.18-2 type-safe Signal Framework for C++
ii libstdc++6 4.3.0-3 The GNU Standard C++ Library v3
ii libxapian15 1.0.5-1 Search engine library
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages aptitude recommends:
ii aptitude-doc-en [aptitude-doc 0.4.11.2-1 English manual for aptitude, a ter
ii libparse-debianchangelog-perl 1.1.1-2 parse Debian changelogs and output
-- no debconf information
Changed Bug title to `apt: autoremoval keeps all branches of an OR on the system even if I don't want one' from `aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5'.
Request was from Daniel Burrows <[email protected]>
to [email protected].
(Tue, 22 Apr 2008 02:15:06 GMT) (full text, mbox, link).
Subject: Re: Bug#477166: aptitude: Does not automatically remove
python-elementtree after upgrading python to 2.5
Date: Mon, 21 Apr 2008 19:13:43 -0700
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
Acknowledgement sent
to Vincent Lefevre <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sun, 21 Apr 2024 02:30:02 GMT) (full text, mbox, link).
Subject: Re: Bug#477166: aptitude: Does not automatically remove
python-elementtree after upgrading python to 2.5
Date: Sun, 21 Apr 2024 04:26:36 +0200
On 2008-04-21 19:13:43 -0700, Daniel Burrows wrote:
[...]
> 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 this does not apply to transitional packages, I've submitted
a new bug for the case where such packages appear in a OR dependency:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069585
This now also becomes more important as deborphan has been removed
from Debian, so that one can only rely on "apt autoremove".
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)