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

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



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.

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


Reply to: