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

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: