Bug#477166: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5

[Vincent Lefevre]

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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#477166: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5

[Sven Joachim]

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.11Advanced front-end for dpkg
ii  libc6  2.7-10GNU C Library: Shared libraries
ii  libcwidget30.5.11-1  high-level terminal interface libr
ii  libept00.5.17High-level library for managing De
ii  libgcc11:4.3.0-3 GCC support library
ii  libncursesw5   5.6+20080405-1Shared 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  libxapian151.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-2parse Debian changelogs and output

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#477166: aptitude: Does not automatically remove python-elementtree after upgrading python to 2.5

[Daniel Burrows]

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]