On Thu, Aug 20, 2009 at 12:56:29AM +0200, Serafeim Zanikolas wrote: > [I'm not switching to private emails as we're getting valuable feedback here] > > On Tue, Aug 18, 2009 at 11:34:11PM +0100, Roger Leigh wrote [edited]: > > Alternatively, the xinetd format is /currently/ the superset, but that's > > perhaps not flexible enough for the future since we're then tied into being > > compatible with that single implementation. > > Please see my email to Russ. I've seen it and agree with this. > > The next bit would be writing the update-inetd replacement (which > > could just be part of the existing update-inetd, used when called > > with no arguments, and/or run on every invocation). If called with > > arguments, it will work as usual; the old code would be removed > > after the transition is done so it just does nothing, or emits > > a warning. > > I'd prefer something more explicit: maintain update-inetd as is, and add > update-inetd-ng. (Also, because I'd rather write the new functionality in > python. I like perl but I'm more confident with python). I'm not sure if update-inetd is still pulled into base installs, but it may well drag in python into default installs, which will bloat its size somewhat. For this reason, I would prefer to stick with perl, but it's your choice. Since xinetd already has the parsing code, it might be worth looking at that as a starting point (xinetd/confparse.c, I think). > I've filed an ITA for update-inetd (#472470). Short-term action plan: > > - prepare a release to take ownership of the package and fix some major bugs > (sponsorship anyone?) > - write and document update-inetd-ng > - provide migration guidelines and modify packages to use both scripts 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. 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. 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