Bug#71621: Policy on update-alternatives still needed
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 [cjwatson@debian.org]
Reply to: