The bug is still present in 1.11.1-1, though I see the minor variation that /usr/bin/aclocal and /etc/alternatives/aclocal are now like the corresponding automake files (ultimately a broken symlink):
lrwxrwxrwx ... /etc/alternatives/aclocal -> /usr/bin/aclocal-1.10 lrwxrwxrwx ... /etc/alternatives/automake -> /usr/bin/automake-1.10 lrwxrwxrwx ... /usr/bin/aclocal -> /etc/alternatives/aclocal lrwxrwxrwx ... /usr/bin/automake -> /etc/alternatives/automake I'm just about to go to bed, and haven't finished debugging this, but I suspect that there's a step missing in the "how to reproduce" instructions: I suspect that this bug only occurs after having automake 1.10 installed and then upgrading to automake 1.11 (or 1.11.1). So first install automake 1.10 (I used 1.10.1-3), then do `update-alternatives --auto automake', then install automake 1.11.1. When upgrading to 1.11.1, first automake 1.10's prerm is called with $1=upgrade (and $2=1:1.11.1-1), so it doesn't do its update-alternatives --remove command, even though /usr/bin/automake-1.10 and /usr/bin/aclocal-1.10 are disappearing. Then when automake 1.11.1's postinst gets run, it unconditionally runs `update-alternatives --install ...', but update-alternatives apparently decides that the setting is manual: it leaves automake pointing to /usr/bin/automake-1.10. If I modify /usr/sbin/update-alternatives to make its initial/default $verbosemode value from 0 to 1, then it gives the following when upgrading from 1.10 to 1.11.1: Alternative for automake points to /usr/bin/automake-1.10 - which wasn't found. Removing from list of alternatives. /etc/alternatives/automake has been changed (manually or by a script). Switching to manual updates only. Checking available versions of automake, updating links in /etc/alternatives ... (You may modify the symlinks there yourself if desired - see `man ln'.) Automatic updates of /etc/alternatives/automake are disabled, leaving it alone. To return to automatic updates use `update-alternatives --auto automake'. Given that we can't change the already-released automake 1.10.1-3 prerm, perhaps for the fix the new scripts should start by calling `update-alternatives --remove automake /usr/bin/automake-1.10'. I haven't checked how --remove behaves if /usr/bin/automake-1.10 isn't present, so it may be best for this to be in preinst, which is run when the previous version's files are still present on the filesystem. However, note that this won't be enough if automake 1.11.1-1 has already been installed (causing update-alternatives to mark in its database that the automake group is set manually). The best fix I can think of for that case is to be a bit brutal: manually check whether automake points to a non-existent 1.10, and if so then call update-alternatives --auto automake. (`readlink' has been in coreutils since v4.5.5, present in Debian unstable since Feb 2003, so present in both Debian v4.0 (etch) and v5.0 (lenny), and coreutils has apparently been `Essential: yes' as long as the package has existed, so we can assume its presence via the "Debian does not support upgrading across more than one stable release" rule, so it should be fine to use the readlink program without adding a versioned dependency.) It's now well past my bedtime, but I hope that's a good start towards understanding how this bug is occurring, and what a fix might be. Btw, just in case you wish to consult it, the sequence for when the prerm etc. scripts get called and with what arguments isn't in the first couple of places I looked for it (developers-reference, dpkg documentation, /usr/share/doc/debian), it's actually in /usr/share/doc/debian-policy/policy.*. pjrm. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
