Bug#71621: Policy on update-alternatives still needed
On Sat, Mar 15, 2008 at 05:25:56PM +0000, Ian Jackson wrote:
> Colin Watson writes ("Bug#71621: Policy on update-alternatives still needed"):
> > 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.
> Another way to look at this is as a bug in update-alternatives.
> Generally we arrange things so that maintainer scripts should not look
> at $1 except in special circumstances. This eliminates many large
> classes of potential bug. It would seem preferable to arrange that
> this be the case for u-a too.
> We could make update-alternatives
> * retain and use the manual setting of the link by a not-currently
> provided alternative, ie make the alternative be ENOENT
> when the user's manual selection goes away (temporarily or
> permanently)
It seems to me that this would just be trading one bug for another. Having
an alternative that was manually set remain pointed indefinitely at a
missing file after package removal, until the user notices and resets it,
doesn't sound like a desirable user experience to me.
> * retain the manual configuration but simply not use it when
> then user's manual selection is unavailable.
That sounds more promising to me.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: