[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFC: update-inetd migration to dpkp-triggers

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

> > * 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?


  .''`.  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

Reply to: