Simon Richter <s...@debian.org> writes: > This would not work for a package like postfix, which absolutely > requires system-specific configuration, and we'd have to be careful with > packages like postgresql where there is a default configuration that > works fine for hobbyists that we do not make life too difficult for > professional users.
I don't think there's any desire to avoid system-specific configuration. The model instead is that the package comes with a set of defaults, and if you don't set something in the local configuration in /etc, the default is used. I think this is exactly the model used by Postfix for main.cf. There are a few mandatory settings, but for the most part you can omit any setting and the default is used. The defaults are just hard-coded (at least so far as I know) rather than stored in separate configuration files in /usr, which doesn't make a fundamental difference. The problem configuration files are ones like Postfix's master.cf, where a whole ton of stuff almost no one ever changes is mixed into the same file that you're supposed to change for local configuration and there's no merger process. And honestly I have always hated the Postfix master.cf file, dating back to before systemd even existed. I think it's a bad configuration design. That of course is just my opinion and doesn't get us anywhere closer to using a defaults plus overrides syntax for master.cf, even assuming that upstream would consider it. There are a ton of packages with configuration syntaxes that were created a very long time ago or have accumulated over time. I maintain one of them upstream, INN, and I'll be the first to say that the INN configuration syntax is *awful*, and I have actively contributed to making it what it is. There are dozens of files, they use about fourteen completely separate and incompatible syntaxes, there's boilerplate in some places and defaults in other places, and learning all the ins and outs of the configuration is a full-time job. It's nonsense, and it's badly designed, and if I were writing it from scratch I'd replace the whole thing with simplified YAML or some similar well-known syntax with a schema and good editor support and a data model that supports configuration merging. And the chances of any of that happening when I have more free software projects lying on the floor in pieces than I have ones I'm managing to keep in the air is... low, even though I do have a much more active comaintainer. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
