On Tue, Sep 08, 2009 at 01:13:45AM +0200, Serafeim Zanikolas wrote: > 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) The --remove option is specified to accept a regexp as its argument. Does this not work? Perhaps packages today aren't /using/ --remove in a way that's robust and idempotent, but again, that seems to be a documentation problem. (The issue you've highlighted here is one I wasn't aware of, thank you for bringing it to my attention. The packages I maintain that use update-inetd are the only things in the archive providing the service in question, so I'd always considered using the service name to be unambiguous.) > 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? Because inetd.conf is configuration data, and packages should not remove these entries when the package is removed - only when the package is purged. > Shouldn't maintainer scripts only use add and remove? (If you disagree, have a > look at #168847) Ah, another case that I hadn't considered because I don't have to deal with multiple packages providing the same service. Wouldn't it suffice to support an additional --pattern argument to update-inetd --add? That way packages could specify the minimal match needed for re-enabling instead of adding a new entry. Alternatively, packages could use --comment-chars '#<removed># ' for enabling/disabling as part of a package removal. Again, the problem doesn't seem to be a limitation in update-inetd, but a lack of policy/documentation around it. Here's a rough cut at a robust set of update-inetd calls for maintainer scripts to use. It's ugly, of course, and verbose - something that could probably be remedied with only minor enhancements to update-inetd. And it seems to run afoul of a bug in update-inetd --remove, in that you can't use a regexp match against the whole line. But those issues can be solved without redesigning the world. package1.preinst: if [ "x$1" = "xinstall" ] && [ -n "$2" ]; then update-inetd --comment-chars '#<removed># ' \ --pattern 'tcp.*/usr/sbin/inetd-test\b' \ --enable inetd-test update-inetd \ --pattern 'tcp.*/usr/sbin/inetd-test\b' \ --disable inetd-test fi package1.postinst: update-inetd --group OTHER --add \ 'inetd-test\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbin/inetd-test' package1.postrm: case $1 in remove) update-inetd --comment-chars '#<removed># ' \ --pattern 'tcp.*/usr/sbin/inetd-test\b' \ --disable inetd-test ;; purge) if [ -x /usr/sbin/update-inetd ]; then # FIXME: why doesn't this regexp match? update-inetd --remove \ '(#<removed># |#<off># )*inetd-test.*tcp.*/usr/sbin/inetd-test\b' fi ;; esac package2.postinst: update-inetd --group OTHER --add \ 'inetd-test\t\tstream\ttcp\tnowait.400\troot\t/usr/sbin/tcpd\t/usr/sbin/inetd-test2' -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature