On Thu, Mar 12, 2009 at 09:22:50AM +1100, Brian May wrote: > Roger Leigh wrote: > > I did propose we switch to inetd-using packages providing a > > config file fragment in e.g. /etc/inetd.d, and having update-inetd > > simply regenerate inetd.conf from these pieces (and it would > > be trivial for it to preserve user edits with this mechanism), > > and it would also be idempotent. It has the benefits of simplicity > > and robustness, since it doesn't require calling a postinst script > > to run update-inetd with a specific (and limited) set of options. > > The current approach relies of update-inetd being hugely complex, > > when it really doesn't need to be. > > > > Ideally we need something that isn't specific to the format of > inetd.conf - last I checked some of our inetd's use different file > formats (e.g. xinetd). Totally agreed. If we support a superset of all of the various inetd configuration options, then it should be possible to support all inetd implementations as first-class citizens (e.g. xinetd). Implementations can then feel free to ignore options they can't support (such as the extended xinetd options, or particular socket options). The format needn't be that complex. If we have one file per package/service, it could just be a simple set of key-value pairs. Each inetd could provide their own update-inetd which just parses the file and spits out their config. Since most inetds have a common format, it might make sense to have a package providing this lowest common denominator implementation. If we have a big comment at the top of the generated file saying in effect "do not edit; edit /etc/inetd.conf.d/xxx and run update-inetd", we shouldn't have too many problems. It's already done elsewhere. Regards, Roger -- .''`. 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