On Sun, Sep 06, 2009 at 11:30:25PM +0200, Marco d'Itri wrote: > On Sep 04, Serafeim Zanikolas <serzan@hellug.gr> wrote: > > > As the new vict^Wmaintainer of update-inetd, I'd appreciate a review of the > > proposal below to migrate it to dpkg triggers [0] > Maybe you could have discussed it with the former maintainer, so I could > have explained why I never implemented the changes you are proposing. I suggested that Serafeim post the proposal to -devel for wider discussion, after it got to the point where it was reasonably complete and coherent and would benefit from wider criticism. I'm not sure what private discussion would have achieved that -devel would not; the proposal does affect a number of packages, and other people may have insights in addition to your input as the ex-maintainer. > For a start, (x)inetd is used by less and less programs, are the changes > you are planning justified considering that we have lived with the > current limitations for 15 years without significant troubles? > And do we really need all the complexity to support xinetd, which is > installed by 3.8% of the users? It's not just about supporting xinetd, as I hope the initial post made clear. It's using the xinetd syntax certainly (why reinvent the wheel when you can reuse the format as the superset used by all existing inetds?), but the primary benefits are making inetd support in maintainer scripts both robust and idempotent. The current update-inetd implementation is flaky junk which is used both incorrectly and inconsistently, and can cause loss of system customisation by the sysadmin as a result. > > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate > This is unacceptable, and I say this as the openbsd-inetd maintainer > (which is another reason why you should have discussed this first with > the other maintainers involved). > /etc/inetd.conf is a well known UNIX interface and it must continue to > be supported, at least for locally-configured services. As Serafeim mentioned, this will continue to be supported. If present, any entries in /etc/inetd.conf will take precedence over any fragment for the same service (it will warn in this case that there are duplicates). This would be the case for at least Squeeze+1 and, if this is a requirement, could be kept indefinitely. If it wasn't clear from the initial post and replies, update-inetd, in addition to continuing to perform its traditional role, will read /etc/inetd.conf *plus* the fragments in /etc/inetd.conf.d, and generate the inetd configuration file under /var from the combination of the two. This will allow a smooth migration as both old and new sources are used. > > * document that local policy will live in /etc/inetd.conf.d/ and any manual > > changes will be made effective by running update-inetd > I also consider not acceptable that manual configuration changes are > ignored unless some program is run. There are many obvious examples of update-foo scripts which behave in this manner. The requirement to run a script to update the working configuration is nothing new in Debian. 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