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