Daniel Gröber <d...@darkboxed.org> writes: >> Any configuration files created or used by your package must reside >> in /etc.
> Pretty clear cut in my reading, however this was promptly shot down by > Bastian <waldi> with the justification: Configuration file has a very specific meaning in Policy: it's a file that the local system administrator changes in order to configure the software. If the file is not intended to be modified to configure the software, it's not a configuration file, even if it contains configuration defaults. See: https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files although it doesn't make this as clear as it should be because it was written before split configurations became common. That's because the main point of distinguishing configuration files (in addition to collecting them in /etc for the use of things like etckeeper) is to ensure that we handle the modifications correctly, don't lose them during upgrades, etc. Static files that aren't modified by the local administrator don't need that special handling. Having the configuration *defaults* exist as a static file on disk in /usr/lib isn't really that different than having the configuration defaults exist hard-coded into the binary, which has been common for many years. Either way, what Debian requires is that the defaults be modified by putting files into /etc, so as long as that continues to be true, this is satisfying Debian's configuration requirement. This isn't that different than long-standing UNIX precedent, as seen in packages such as postfix or INN or any number of other programs that support configuration files in /etc but have a large number of hard-coded defaults that apply if those files are missing or don't set that option. I should say explicitly that none of this addresses the *preference* argument between people who prefer to have the defaults in /usr and overrides in /etc, and people who prefer to have all of the settings in /etc so that they are readily visible for modification. Some people prefer one, some people prefer the other, and both sides feel strongly about it and probably won't convince the other side. But this conflict has existed for essentially forever in the form of defaults that are hard-coded into the binary and not expressed in the sample configuration file, so it's not really a new conflict, and I think it's more transparent to have defaults in a separate file in /usr than hard-coded into a compiled binary. I do understand why folks who prefer the "all settings in one modifyable file in /etc" are annoyed when packages move to the split configuration model with a file of defaults in /usr, but it's not something that Policy requires one way or the other and there are vigorous advocates of both methods. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
