On Thu, Nov 29, 2007 at 10:17:22PM +0000, Roger Leigh wrote: > The main problem (as I see it) is that the current update-inetd is too > complex, and can't migrate configurations between different inetd > config file formats.
Why should that be the job of the current update-inetd? > And every maintainer script has to call update-inetd to make it write > package-specific information, which is fragile Fragile in what sense? > it only gets done when you install the package, and if you screw up > inetd.conf, too bad. Er? Screw it up how? Why would it not be fixable with dpkg-reconfigure $package? > Why don't we take a leaf out of how other packages manage things and > do this: > - create a /etc/inetd.d directory > - each package providing an inetd service can contain a > /etc/inetd.d/package file containing all the information about the > service; it could be a superset of the information xinetd and all > the other inet daemons require, and have a parameter to > enable/disable the service. This should be a conffile. > - update-inetd takes no arguments, it just reads all the files in > /etc/inetd.d/ and then writes out an inetd.conf, or xinetd configs, > whatever the daemon requires. > This has the big advantage of > - allowing the user-customisable bits to be in conffiles for > preservation across upgrades > - makes the whole thing much simpler, maintainable and extensible > - each inetd can provide a *trivial* update-inetd to read through the > config files Using conffiles is a big *DIS*advantage. Conffiles are only minimally appropriate when there's a stock config which is expected to work for most users, and in the best of cases are annoying for users who diverge even minimally. When we're potentially talking about a config file format that contains the information about whether a service is enabled or disabled, that's a Bad Idea. You're also talking about a totally new config format that nothing actually *reads* today, so now instead of doing the right thing and teaching a tool to parse & output the existing formats, we instead have a tool that parses one format and outputs another with the result that there are two copies of the information stored on the system - one in the place where existing users expect to find it which is *not* authoritative, and one in a totally new format that is authoritative. This is also a Bad Idea. -- 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/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]