On Thu, Jan 11, 2007 at 01:40:21PM +1100, Brian May wrote:
> We really need a constant way of dealing with this in package updates.
> Currently I have two very opposing views, and not entirely convinced
> in either of them.
How are these in opposition? Andi's mail says that you shouldn't touch
inetd at all on upgrades if there are no configuration changes that need to
be made. Clearly Peter wasn't reporting a bug because heimdal-kdc *didn't*
touch inetd, he was reporting a bug because it *did* touch it.
> It seems to boil down to:
> * should packages disable inetd config entries on removal and in
> preparation for upgrade, and then reenable the entries after upgrade
> is complete?
No, they shouldn't, because this loses local modifications to the inetd.conf
line. Even if not explicitly required by policy, we should make every
effort to preserve the admin's local changes here.
What's the downside to leaving services enabled during an upgrade? Is there
a failure mode we need to worry about here other than the service just
aborting on connect?
> * what about entries that should be disabled by default? That is the
> maintainer has decided the majority of users will not need it?
Why pretend to provide support for such a service *at all* then, if you're
just going to wipe out the admin's choice on every upgrade?
> * is solving this worthy of etch?
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.