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)
