Bug#37254: dpkg: update-alternatives madness
Package: dpkg
Version: 1.4.1.1
Severity: important
I just filed a bug against tkstep8.0 for its handling of alternatives (and I
have filed similar bugs against several other packages), but I think the
situation points to important problems with the update-alternatives program.
First, update-alternatives does undesirable things when called upon to
remove an alternative when the targets of the links are gone. This can
happen when a package in removed, or when a package is upgraded and
filenames change. The result is that update-alternatives notices the
targets missing, removers the alternatives for the missing targets, and then
(the mistake) decides to put the alternative into manual mode. This is very
undesirable and has already broken several of my package upgrades and
uninstalls. Possibly, this is in part due to mistakes by packagers (more
below), but update-alternatives should handle it better. I suggest that
update-alternatives not put alternatives into manual mode when the targets
of the /etc/alternatives symlinks are missing. Obviously, an administrator
would not do this on purpose, so switching to manual mode is silly.
Second, update-alternatives does bad things when packagers are sloppy with
there slave alternatives. In the case of tkstep8.0, the alternative was
wish. tk8.0 registered an alternative for /usr/bin/wish (pointing to
/usr/bin/wish8.0) and /usr/man/man1/wish.1.gz (pointing to
/usr/man/man1/wish8.0.1). tkstep8.0 registers its own targets for these,
but also creates an alternative for /usr/bin/wish8.0 . This is clearly
wrongheaded, because that is the binary for tk8.0. Fortunately,
update-alternatives notices this when registering the alternative (reporting
"readlink failed") and does not overwrite it. Unfortunately, it doesn't
notice this when tkstep8.0 is removed. It reports "Discarding obsolete
slave link wish8.0 (/usr/bin/wish8.0)." and deletes the binary
/usr/bin/wish8.0. update-alternatives should probable make sure that it is
a link into /etc/alternatives before deleting it.
Third, there is clearly a need for a better policy for developers. I know
that alternatives-related problems during upgrades and removes have made a
mess of several systems. At least the following need to be addressed:
- Alternatives should be unregistered in the prerm, so that the target files
will still exist; otherwise update-alternatives will get confused. Of
course, update-alternatives should handle the problem more gracefully.
- Packages should avoid changing the names of the targets of alternatives
during upgrades, or should be instructed on how to handle the case.
Again, update-alternatives needs to be more forgiving.
- Packages should always provide the same set of slave alternatives for a
given alternative.
See also my post of April 21, 1999 to debian-devel responding to the subject
"Master".
I am not a Debian developer, but I would be happy to help you resolve the
alternatives morass.
Thank you,
Andrew
-- System Information
Debian Release: potato
Kernel Version: Linux nolfolan 2.2.7 #1 Fri Apr 30 07:54:26 EDT 1999 i686 unknown
Versions of the packages dpkg depends on:
ii libc6 2.1.1-2 GNU C Library: Shared libraries and timezone
ii libncurses4 4.2-3.2 Shared libraries for terminal handling
ii libstdc++2.9 2.91.61-1 The GNU stdc++ library (egcs version)
Reply to: