Hi Ian, Ian Jackson wrote: >> On Sat, Mar 15, 2008 at 05:25:56PM +0000, Ian Jackson wrote:
>>> * retain the manual configuration but simply not use it when >>> then user's manual selection is unavailable. [...] > If we do this and retain the existing maintainer scripts then > everything will be fine *except* that while (say) nvi is unpacked but > not configured, the system will mysteriously use vim (say) instead. > > Perhaps more thought is actually needed. I really don't like the idea > of asking maintainers to switch on $1. That always goes wrong. But > we could ask them to pass their $1 to u-a ? > > Also, if the package is unpacked because it was just upgraded, and you > then say --remove, the prerm isn't run. So just checking $1 in the > prerm isn't sufficient. It has to be done in the postrm (as well, if > not only). I would like to revive this thread, because I think you were right about in an ideal world not needing to check $1 in maintainer scripts. The first question: what should the behavior be? I. If the user does not express a preference. If the user has not explicitly chosen an alternative, it might seem that there is nothing to worry about. Just use the highest-priority alternative that is configured at any given moment. But that is not quite right, because: - sometimes no alternative is configured; - a command like "editor" toggling during each upgrade between different interfaces would be unpleasant. What we actually want is the highest-priority alternative that is usable, which is to say, the highest-priority alternative that was completely configured at some point and was not removed since then. Meaning: * when the package is configured, register the alternative; * when the package is removed, unregister the alternative. Following this line of logic, - preinst would never install an alternative; - postinst would always install an alternative; - prerm remove would remove an alternative, but prerm upgrade and prerm deconfigure would leave well enough alone; - postrm remove and disappear would remove an alternative, but postrm upgrade would leave well enough alone. > That means that while the package is being removed, it will inevitably > sometimes leave a broken alternative. Won't prerm remove take care of it? Hints welcome, as always. Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
