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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]