Re: Processed: severity of 216768 is important
I though it would obvious that this bug is severity important. It seems
that this assumption was wrong.
On Tue, Jan 19, 2010 at 12:03:27PM +0100, David Kalnischkies wrote:
> >> severity 216768 important
>
> >important
> > a bug which has a major effect on the usability of a package,
> > without rendering it completely unusable to everyone.
dpkg checks if the installed version of a package is essential and it
does not care whether there is another version available of this package
which is essential [1] (nor could it care, since it does not know about
these other packages). I think it is perfectly valid for other packages
to rely on the information dpkg provides and uses itself and don't ask
a widely used and important dpkg frontend instead for this information.
debfoster and deborphan do this, they parse the status file to decide
which packages can be removed.
debfoster asks which packages one wants to keep an feeds the resulting
list of removable packages to apt. With two packages being essential in
stable but not in testing or unstable this "inconsistency" in deciding
which packages are essential between apt and dpkg, the described
behaviour can easily lead to errors [2] that are confusing many users,
given that stable is still in their sources.list, which is not that
uncommon whilst upgrading to a new release.
deborphan is very conservative when called without commandline arguments
and only prints packages with no reverse dependencies, recommends or
suggests which are in section libs or oldlibs (it also checks the
priority, essentialness and the dpkg hold flags). People seem to trust
this algorithm, since someone introduced deborphan on debaday [3] some
even feed its output recursively to aptitude purge, I also saw similar
constructs using deborphan, apt and cron. There are less conservative
settings available, but these are accordingly documented as being not
that reliable and people normally don't blindly trust them.
Strictly speaking diff and mktemp don't belong to the section oldlibs.
In the past fileutils, textutils and shellutils also did not fit to this
section but nevertheless have been put into it, one justification for
this was that deborphan would list them by default. I suspect the same
reason for putting diff and mktemp to oldlibs.
Displaying them by default although they can't non-interactively be
removed by apt without using --force-yes breaks besides above mentioned
home-brew hacks also orphaner. Orphaner is a curses based fronted for
deborphan which passes all non-orphaner options to deborphan and let the
user choose packages he or she wants to remove. To double check the
dependencies, avoid problems if someone removes or installs packages
whilst running orphaner and to ensure DPkg::{Pre,Post}-Invoke (which
IMHO would be better fit to dpkg itself instead of apt) is run, it uses
apt-get -f to remove these packages. People expect displayed packages
to be selectable and removable without causing orphaner to fail when
actually trying to remove packages [4]. For experienced users this will
not be a real problem, but for those who don't know how to use dpkg to
remove packages or not being aware of the fact that apt and dpkg
consider different packages as essential this will be a great deal of
annoyance, they will run into this problem every time they don't
remember to skip diff and mktemp and they will loose their carefully
chosen list of to be removed packages.
This nearly fits the decription:
| a bug which has a major effect on the usability of a package, without
| rendering it completely unusable to everyone.
..., but a better fit would be:
| a bug which makes unrelated software on the system unusable or mostly
| so, without rendering it completely unusable to everyone.
I still think important is appropriate for this bug. Even without
debfoster and deborphan being less usable because of this bug I would
consider such a behaviour in one of the most critical parts of a Debian
installation to be a important bug, but that's nothing worth being
discussed. You are one of apt's maintainers and if you think this is
only a minor bug it's perfectly ok, just set the severity you think is
adequate.
> Btw, my answer[5] to the bugreport still stands and even some
> bugreporters [6] came to the same conclusion before...
Apt can't and doesn't ensure that people who mix distributions and
install a single packages from e.g. unstable on their stable system
install all packages that are essential in unstable (they are installed
whilst doing a dist-upgrade, but not whilst doing an upgrade or
install). Pulling essential packages from all distribution during
dist-upgrades as apt currently does seems like a sane solution for
ensuring new essential packages are not missed. Simple upgrades don't
remove nor install packages, so they can be ignored for now.
When one tries to remove a packages there are basically two cases:
If the currently installed version is essential apt should and does per
default refuse to remove it, as dpkg does.
The other case is when you want to remove a package that is in the
installed version not essential but is essential in another version and
this is where our opinions currently differ. The main advantages of
removing such a package if requested are not needlessly confusing users,
not breaking tools relying only on the information provided by the
status file like debfoster and deborphan and more consistency between
dpkg and apt. The advantage of refusing such a package is to prevent
users from doing stupid things and breaking their system. You
differentiate between three cases, removing a package that "is", "was"
and "will be" essential. "Is": Nobody expects packages that are
currently essential to be easily removable by apt. "Will:" As explained
above, apt does not enforce installing these packages unless you do
a dist-upgrade, I see no real benefit if apt doesn't let you remove
packages it never forced to be installed, this would guarantee nothing.
"Was": I consider this to be rather rare and don't remember that this
has ever happend (except simple renames like diff -> diffutils that only
require a simple transitional package), but if this will really happen
in future it could be handled by proper dependencies of the transitional
package and e.g. other essential packages, the latter would only be
needed for one release cycle since we don't support skip upgrades.
Regards
Carsten
[1] $ grep ' stable ' /etc/apt/sources.list | line
deb http://ftp.de.debian.org/debian stable main contrib non-free
$ dpkg -r diff
(Reading database ... 20425 files and directories currently installed.)
Removing diff ...
$ dpkg -r diffutils
dpkg: error processing diffutils (--remove):
This is an essential package - it should not be removed.
Errors were encountered while processing:
diffutils
[2] $ debfoster
Keep diff? [Ynpsiuqx?], [H]elp: N
Keep mktemp? [Ynpsiuqx?], [H]elp: N
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
diff* mktemp*
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
diff mktemp
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 53.2kB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
?]
[3] http://debaday.debian.net/2007/10/21/deborphan-find-packages-you-dont-want/
or
http://web.archive.org/web/20080614041639/http://debaday.debian.net/2007/10/21/deborphan-find-packages-you-dont-want/
[4] Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
diff mktemp
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
diff mktemp
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 53.2kB disk space will be freed.
E: There are problems and -y was used without --force-yes
[5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544481#86
[6] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=216768#36
Reply to: