On Sat, Aug 22, 2009 at 10:33:51PM +0200, Serafeim Zanikolas wrote: > On Thu, Aug 20, 2009 at 11:08:40AM +0100, Roger Leigh wrote [edited]: > > Sounds good. inetd-base might be a slightly better name, since it's > > something all the inetd implementations will depend upon (but packages > > /providing/ inetd fragments won't need to, since the TTBOMK file > > triggers happen transparently). This will mean these packages won't > > need to do anything except provide the config fragment. > > That's fine by me. I understand that renaming a pkg can be done transparently > (wrt rdepends) using replaces+provides+conflicts against update-inetd > (according to devref 5.9.3). In that case I'll use /etc/inetd.base.d instead > of /etc/inetd.conf.d That should be fine. However, if you implement this in the existing update-inetd, you won't need to do any migration. > (I suppose it's OK to close bugs belonging to update-inetd from the changelog > of inetd-base) I would reassign them first, though it should be fine. > > I'm not sure if any additional steps would need to be taken on removal, e.g. > > if the service should be stopped in prerm. > > If I understand correctly, this is an issue only for standalone servers, not > for services instantiated by inetd (those will seize to run as soon as the > server binary is gone and any pending instances exit). I think this should be correct, though any running servers may not be overly happy over having their files removed as they are running (though this shouldn't be much of a problem in practice; it's something non-inetd using servers could potentially also suffer from if they fork off a child to handle a connection during removal). > Removed packages should definitely call update-inetd, to give it a chance to > go through the fragments in /etc/inetd.base.d, set ``disable=yes'' to those > that refer to non-existent server binaries, and update the actual (x)inetd > configuration. (Otherwise (x)inetd will spam logs for failing to invoke > missing servers) I hadn't fully considered the case where you have removed the package but not purged the config files. It's not really appropriate to alter the user configuration. The approach I would take here is to check the state of the package owning the file, and to skip it if its state is not "installed". If there's no reference to the package then you don't skip, since it's probably a custom fragment added by the admin. You can't check for the presence of the program, since for many it will be TCP wrappers (/usr/sbin/tcpd), so it probably should be the package state. This needs some more thought, since doing it via dpkg -S will be slow. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
Attachment:
signature.asc
Description: Digital signature