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

Package:
apt
Source:
apt
Description:
commandline package manager
Submitter:
Tuomas Noraef
Date:
2010-08-19 14:18:12 UTC
Severity:
normal
#593562#5
Date:
2010-08-19 09:34:49 UTC
From:
To:
*** 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.

#593562#10
Date:
2010-08-19 14:15:59 UTC
From:
To:
Hi Tuomas Noraef,

Before i comment: Calm down a bit. Regardless how fucking serious
a bug might be in your or everybody else eyes is (or not is),
swearing will not help in getting it resolved as swearing doesn't
motivate anybody to do anything expect response with more swearing
maybe.

2010/8/19 Tuomas Noraef <tnoraef@gmail.com>:

The autoinstalled stuff is a good feature in the right hands,
but need serious hand-holding in either ways as APT has not enough
information to give always the correct answer:
Just because a package was once installed automatic by another
package doesn't mean that the user doesn't depend on it in the mean
while and should have marked it as manual…
Many people complain about this situation in which too much is removed.
Your case is the opposite, but you are complaining at least as loudly,
so regardless how far APT is pushed to suit one of the sides better,
the other side will complain, so it sits in a reasonable place somewhere
in the middle and get complains from both sides. :)
The package is part of a dependency chain (even if its only an or-group)
and therefore is still "needed".
Your case is special as your really have one solver which is marked
as manual - APT just doesn't check in an or-group if one of those is
marked as manual.¹
It assumes always the all-automatic case in which it follows all
dependencies as it can't really choose between the options.
In theory APT should delay decisions for or-groups (not only here
also at other places) until it has marked all the non-or-group dependencies,
but it doesn't so far and it would be a non-trivial change for a not
so mission-critical thing in most cases => Nothing for squeeze…

¹ it doesn't check the autobit in this stage at all: It simple walks over the
dependencies and checks which aren't reached and are not manual
installed - those are candidates for autoremove…
Depends are easy: If the application doesn't start without them,
it must be listed in Depends - but the rest is a bit flacky and
depends on your usecase: Using applications without the soft
dependencies is possible, but some usecases will not be possible.
Rating which usecase is important enough to grant recommends
instead of suggests is up to the maintainer…
but you should consider writing bugreports in these cases.
It will at least help more than complaining in general about it at
places nobody will hear it, as APT bugs aren't of general public
interest most of the time…
And yes, recommends and suggests could be improved, e.g. by
describing somewhere easily findable why a package is marked
as such for this package, but that is really not the topic for this bug…

Lot of disk space is not everywhere available, so it is no excuse,
but putting the complete responsibility on APTs shoulders is a bit
simple…

At least debootstrap will install very few packages which aren't required -
and required packages are not considered for autoremove…

Feel free to share your homemade script and
feel even free to patch APT directly.
The APT team (as many other teams) is seriously understaffed,
so don't expect us to instantly jump at it - but do it yourself for
the community instead - we will at least try to help you doing it. :)

Could you elaborate more in which way APT is a "whole mess"?
Bugreports and/or patches optional.

As i said, a machine can only work on the data it has and it has not enough.

I think APT does a reasonable job most of the time - everytime it does it
saves me a lot of time, everytime it doesn't is bad, but at least i haven't
lost time as without APT i would have to do it on my own anyway…

And nobody stops me from helping to make APT more intelligent to save me
the time next time i hit a similar problem… software doesn't get magical
better by complaining about it, it can be made better only with patches
and thankfully the source is available so everybody can help and is not
forces in the (unsatisfied) receiver position all the time…


Best regards

David Kalnischkies