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). -- Brian May <br...@microcomaustralia.com.au> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
