On Sep 04, Serafeim Zanikolas <ser...@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.
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? > * 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. > * 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. > * should version-depend in the update-inetd version that is shipped in > squeeze (so that /etc/inetd.conf.d/ is in place) Hint: at this point, you can as well create a new package with a different name which will use the new interface. > * all deamon packages that use update-inetd [1]: > * should drop their dependency in update-inetd and should not call > anymore update-inetd in postinst/prerm scripts The only packages which can depend on update-inetd are the ones providing inet-superserver. If any other package is depending on update-inetd it is broken. > [1] 40: the number of update-inetd's rdeps in main/unstable, excluding > ``Provides: inet-superserver'' packages Feel free to file bugs. Other than this, I agree with vorlon's sensible remarks. -- ciao, Marco -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
