Bug#593562: apt: the automatic tag is too strong when dependencies with "logical or" are involved
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>:
> 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.
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. :)
> 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.
What you found here is intended the root cause for your problem:
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…
> 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).
You don't want to hear it, but i will still say it: its a human problem.
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…
> 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
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…
> to clean the mess (like the inability of debootstrap or the debian
> installer to even set automatic tags on packages, for instance).
At least debootstrap will install very few packages which aren't required -
and required packages are not considered for autoremove…
> Discouragement towards this totally borked mess (I for now try to
> repair this clunky situation using python-apt home-made scripts) has
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. :)
> 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).
Could you elaborate more in which way APT is a "whole mess"?
Bugreports and/or patches optional.
> Seriously, package management should not have anything to do with
> package tinkering.
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
Reply to: