Bug#71621: Policy on update-alternatives still needed

[Ian Jackson <ian@davenant.greenend.org.uk>]

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.