[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#593562: apt: the automatic tag is too strong when dependencies with "logical or" are involved



Package: apt
Version: 0.7.25.3
Severity: normal

*** Please type your report below this line ***

Hi,

Having recently marked as "automatically installed" a whole bunch of
packages, so not to have to manually sort which should be removed
without harm, from which whose removal would really bring harm, I have
been a tad upset to realize midori and epiphany-browser had not been
uninstalled. Checking why teached me this was noticeably because of
the sun-java6-plugin.

Its "logical or" dependency upon a whole bunch of packages indeed has
been enough to make APT consider midori and epiphany-browser are used,
even though iceweasel and konqueror are themselves manually installed.
Fiddling a bit about why, I came to realize sun-java6-plugin depends
on a logical "or" in respect with about any browser. Same thing if I
uninstall java6 : the non-free flash-plugin somehow depends on
www-browser, which midori and epihany-browser provide. And it seems to
be a reason enough to keep them ! I guess this crap happens with
anything requiring www-browser, and I also guess this happens whenever
"provides" and "logical ors" are involved.

I should precize I use the APT-wide settings :

Apt::AutoRemove::RecommendsImportant "false";
Apt::Install-Recommends "false";

... and that, for a reason. Before activating those I had about 2500
packages installed on the system I am playing with at this time. After
those, I only have a bit more than 1000 packages installed (and still
a lot I could leave without) : I already seriously thought the
recommends/suggests paradigm was totally broken (why isn't unrar-free
recommended, but only suggested, as are all the other compression
tools, when I ask for ark being installed ? And why are all those
instead only suggested when I install file-roller ? And then, why is
mldonkey-server recommended, and not only suggested, when you install
kmldonkey, which yelds a started-and-stopped-with-an-error init script
at the boot ?). I will never approach again, even with a barepole,
these grotesque and inconsistent notions (don't tell me about a
packaging-human problem : I believe the problem lies in the very
recommends/suggests paradigm, though it is not the place to detail
why).

But now, in my quest to clean the plague, I realized one of the things
I like a lot in Debian (the ability to differentiate automatically
installed packages from manually installed ones) is as much broken.
Install gnome, install java6, remove gnome : and voilà - if you trust
APT, and avoid doing the work it should do on his own, you're stuck
with epiphany-browser (and all the dependencies it pulls, not to speak
about the pile of dirt in the GUI apps menu, or in /usr/share/docs)
forever, even if you have manually specified you really wanted other
browsers... seriously ?

Really, please implement an APT-wide
"Apt:Autoremove::Automatic-logical-when-stronger-request" or such
thing. APT should really be able to think that way (maybe not by
default, to be coherent with the oh-so-wrong way of installing
recommends by default - but this has to be a possibility). Please
realize that having epiphany-browser and midori for the sole purpose
of satisfying immediate (logical) dependencies, which are anyway
already satisfied by stronger wishes (and even if I hadn't konqueror
set manually, I'd still consider it a stronger wish, as KDE being
_manually_ installed on my sytem, and this one depending on konqueror,
it would anyway derive from a direct wish, contrarily to
epiphany-browser, once gnome uninstalled).

Lots of disk space is no excuse for the borking APT is responsible for
these days. And this is only amongst the things that need to be done
to clean the mess (like the inability of debootstrap or the debian
installer to even set automatic tags on packages, for instance).
Discouragement towards this totally borked mess (I for now try to
repair this clunky situation using python-apt home-made scripts) has
even triggered in me a long asleep urge to see what other
distributions do with package managers... Debian-centric as I am, this
tells a lot on the whole mess APT has come to (sad, but true).
Seriously, package management should not have anything to do with
package tinkering.

-- Package-specific info:

-- (no /etc/apt/preferences present) --


-- /etc/apt/sources.list --

deb http://mirror.home-dn.net/debian-multimedia sid main non-free
deb http://ftp2.fr.debian.org/debian/ sid main non-free contrib


-- System Information:
Debian Release: squeeze/sid
 APT prefers unstable
 APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages apt depends on:
ii  debian-archive-keyring        2010.08.15 GnuPG archive keys of the Debian a
ii  libc6                         2.11.2-2   Embedded GNU C Library: Shared lib
ii  libgcc1                       1:4.4.4-8  GCC support library
ii  libstdc++6                    4.4.4-8    The GNU Standard C++ Library v3

apt recommends no packages.

Versions of packages apt suggests:
ii  apt-doc                       0.7.25.3   Documentation for APT
ii  aptitude                      0.6.3-3    terminal-based package manager (te
pn  bzip2                         <none>     (no description available)
pn  dpkg-dev                      <none>     (no description available)
ii  lzma                          4.43-14    Compression method of 7z format in
ii  python-apt                    0.7.96.1   Python interface to libapt-pkg

-- no debconf information



Reply to: