reopen 71621 thanks I recently ran into this yet again, with a set of packages (scim et al) calling update-alternatives --remove in 'prerm upgrade', and thereby breaking user configuration on every upgrade. I do not think that the issue has got significantly better in the 7.5 years since I originally reported this bug.
Manoj closed this bug in 2002 with the comment "Clarifying manual pages is not a policy issue". As I said in response to that at the time: I think #71621 is an interoperability and consistency issue, and thus suitable for policy. For instance, packages that remove and reinstall alternatives on upgrade (at least used to) break local configuration in the form of manually set alternatives, and I believe using update-alternatives in this way could cause alternatives to be sensitive to upgrade ordering when multiple packages providing the same alternative are upgraded in the same run. This feels like exactly the kind of thing that policy ought to mention. Policy documents other matters that consist of instructions on how to use system tools in ways that produce interoperable packages. For example, 8.1.1 "ldconfig", 8.6.2 "How to use dpkg-shlibdeps and the shlibs files", 9.2.2 "UID and GID classes" (adduser --system), and 9.3.3 "Interfacing with the initscript system" (update-rc.d). I do not see how update-alternatives is materially different from these. I'm not asking for policy to duplicate the manual pages. The manual pages tell you how to use the tools to perform specific actions, as they should. I'm asking for something at a higher level: policy should recommend standards for the actions that should be performed using these tools in order to produce packages that form a well-integrated, coherent system. This should not be news: policy already does this in other cases, so I simply want update-alternatives to be added to the family. The reason I care is that this is clearly a matter of great confusion. I don't think it's a matter of strong technical disagreement as such, otherwise I realise that the policy list probably wouldn't be the right place to bring it up; I think it's simply a matter where there is little guidance for developers and so it's easy for people to create subtle bugs, much as they probably would do if e.g. there were no guidance on the proper use of update-rc.d. Based on the analysis I did back in 2000, which I think is still largely sound, I think that policy should recommend that 'update-alternatives --remove' must not be called in any of prerm upgrade, prerm failed-upgrade, postrm upgrade, postrm failed-upgrade, postrm abort-install, or postrm abort-upgrade, because these cases cause an alternative to be removed that may shortly afterwards be reinstalled, which can make update-alternatives erroneously switch the alternative from manual to auto mode. Typically, a package should call 'update-alternatives --remove' in either prerm remove or postrm remove. However, in my original analysis I was unsure about the prerm deconfigure and postrm disappear cases; I would appreciate other contributions here. To go along with this, the result would be more readable and useful if the correct process for installing an alternative were also documented, although this is not something that people get wrong nearly so often. Please reconsider this bug. Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
