[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: update-inetd

Steve Langasek <vorlon@debian.org> writes:

> 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.
>> http://lists.debian.org/debian-devel/2006/12/msg00279.html
>> vs
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401258;msg=98
> 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?
> Yes.

I think this has a rather simple solution (for lenny?).

Create /etc/inetd.conf.d/<package> and have inetd read in all files in
there one after the other.

Packages that want to have inetd support by default can just ship a
conffile and the admin can edit or remove it. Dpkg will keep track of
changes in the conffile and the admins changes automatically.

Packages that want to offer a choice of inetd can use ucf to create
and maintain /etc/inetd.conf.d/<package> manually if the user opts for
inetd support. Again a well proven mechanism.


Reply to: