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)
* retain the manual configuration but simply not use it when
then user's manual selection is unavailable.
Of these I prefer the former. Is there some reason not to ?
Ian.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
