Re: RFC: update-inetd migration to dpkp-triggers
On Mon, Sep 07, 2009 at 01:59:48PM -0700, Steve Langasek wrote [edited]:
> On Mon, Sep 07, 2009 at 09:40:51PM +0100, Roger Leigh wrote:
> > but the primary benefits are making inetd support in maintainer scripts
> > both robust and idempotent.
>
> update-inetd in its present form can already be used to achieve this.
I beg to differ. update-inetd assumes that a service name (``ftp'') is
sufficient to enable, disable and remove a service, whereas to be certain of
what service is selected, one has to additionally specify protocol and path to
the server binary. This currently can be done with a little bit of imagination
using the optional --pattern switch (which strangely though is not available
in --remove mode)
I'll keep improving update-inetd regardless of any migration but the problem
remains: it provides too much flexibility that is naturally abused.
And while we're at it, why does it even have the enable/disable switches?
Shouldn't maintainer scripts only use add and remove? (If you disagree, have a
look at #168847)
--
debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp
Reply to: