On Fri, Sep 04, 2009 at 10:02:21PM -0700, Steve Langasek wrote: > On Fri, Sep 04, 2009 at 09:54:19PM +0200, Serafeim Zanikolas 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] > > > * update-inetd will drop its current switches to > > add/remove/enable/disable services; > > This doesn't sound like a good idea; it sounds like a transition that's > going to break a lot of packages (either silently or noisily, depending on > the implementation). How do you intend to transition away from this without > either a) dropping existing package-provided entries on the floor, or b) > leaving packages with no way to clean up those same entries? This is an area that still needs work IMO. We still need to support uninstallation of programs which use these options, perhaps installed or conffiles-only from a previous release, and as a result we do need to retain these options. In order to support removal of packages, the ability to remove services will need to be retained (perhaps indefinitely?) For installation of old packages, the ability to add packages would also need retaining. However, could this realistically be dropped after a stable release? It could be deprecated and print a nasty warning for one release, which could subsequently be updated to fail. > > * abolish /etc/inetd.conf and /etc/xinetd.d/ and instead auto-generate > > /var/lib/update-inetd/inetd.conf and auto-populate fragments in > > /var/lib/update-inetd/xinetd.d/ using xinetd fragments installed by deamon > > packages in /etc/inetd.conf.d/ > > Likewise, then, what happens to existing entries in /etc/xinetd.d? As mentioned in the other posts in this thread, I think these would continue to be used, and would override the /etc/inetd.conf.d fragments if present. One could move the conffile in the maintainer preinst scripts once the new system was in place, avoiding the duplicates and retaining user changes. > > * document that local policy will live in /etc/inetd.conf.d/ and any manual > > changes will be made effective by running update-inetd > > I think this violates the principle of least surprise (restarting the daemon > after making your changes has been enough to make those changes take effect > since the inception of these daemons), and will be displeasing to many > admins as a result. I can't say that this part thrills me either. However, we have as yet not come up with a saner alternative. > > How to Get There > > > The migration could(?) be done within one stable release, but I assume a more > > conservative approach over two releases. > > > * squeeze > > * all deamon packages that use update-inetd [1]: > > * should version-depend in the update-inetd version that is shipped in > > squeeze (so that /etc/inetd.conf.d/ is in place) > > * should install xinetd fragments in /etc/inetd.conf.d/ (and in > > /etc/xinetd.d/ if they did so already) > > * must continue calling update-inetd in postinst/prerm scripts as > > before > > * update-inetd will: > > * install /etc/inetd.conf.d/ and declare file-trigger interest in it > > * keep the old functionality, but additionally to updating > > /etc/inetd.conf, also update /var/lib/update-inetd/* using as input > > both /etc/inetd.conf and /etc/inetd.conf.d (and /etc/xinetd.d if > > installed) > > So with these packages that are calling update-inetd *and* installing a > snippet, what ends up being copied to /var/lib? This is a combination of the old inetd.conf (or xinetd files) and new xinetd-format fragments, with the old configuration taking precedence where duplicate service entries exist. This will guarantee user changes still take precedence, and allow a smooth transition since the old and new systems will continue to function as inetd-using packages migrate over to fragments. > > * update-inetd must: > > * sync effective inetd configurations based on /etc/inetd.conf.d/ and > > reload inetd when invoked without any arguments > > * only run as as result of being triggered by a deaemon > > (un)installation, or an explicit user invocation > > * drop the old functionality and print a warning but otherwise succeed > > when invoked with any of the old command line switches > > So: silent failure of update-inetd invocations. > > Noisy would be better. Silent failures hide bugs. If --add or --remove are used, but update-inetd no longer takes any action, should package installation still succeed? One wouldn't want any broken maintainer scripts which result in non-removable packages on purge. At the very least, the old options would be deprecated but continue to function exactly as before for at least one stable release. The hard question here is if the old functionality should be disabled or fully removed in the following stable release, and how should it handle failure in this case so as to cause minimal problems? Handling the options would obviously need to remain, even if they did nothing. But, if they take no action, how should that be reflected in the exit status? 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