Daniel Gröber <d...@darkboxed.org> writes: > Ultimately I'm just concerned about the UX aspects of admins suddenly > having to go hunting for config files all over their system when > packages start implementing this config-in-/usr business en mass.
I think the expectation is that you read the documentation of the package that you're configuring, just as if the defaults were all hard-coded in the binary. I realize that some people *prefer* to have all of the configuration of a package documented in comments or settings in a template file installed into /etc, but this has never been something we *required*, just a convention that some packages follow and some do not. > I don't really mind if we go that way but then policy needs to be > updated and some convention or mechanism[1] put in place to make working > with config by hand as easy as it's been in the past, but that work is > on the devs pushing the project in that direction. This is a change that is mostly happening in the upstream development of some packages, so I think your attribution of cause may not be entirely accurate. People are adapting Debian packages to a configuration model that started in other distributions and has been adopted by the upstreams of those packages, and some of them are also advocating for this configuration practice as a good idea, but the push of Debian in that direction would be happening regardless of the opinions of Debian maintainers about this configuration method. Some of our upstreams are adopting this and it's highly unlikely that we would maintain local patches to undo that change. I'm not sure how much of the documentation belongs in Policy, since this is really user-facing documentation, which is entirely outside the remit of Policy. Policy is only about packaging; we don't expect users of Debian systems to read it. But I'd be happy to review a patch that updated the Policy wording of configuration files to make it clear that "configuration files" only refers to the files edited by administrators in the course of configuring the system, not to wherever the read-only configuration defaults may be stored. Obviously if someone wants to write better tools to manage these configuration files, that would be great, but that's outside the scope of this list, and I am dubious that we would refuse to update to newer upstream versions of our packages until someone writes such a tool. We are part of a larger ecosystem, and some critical components of that ecosystem are moving in this direction regardless of what we do. > On Thu, Sep 14, 2023 at 09:41:00AM -0700, Russ Allbery wrote: >> 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. > Sorry, I don't buy that. Policy is kind enough to have an explicit > definition for what it means by "configuration file" in > 10.7.1. Definitions: >> configuration file >> >> A file that affects the operation of a program, or provides site- or >> host-specific information, or otherwise customizes the behavior of a >> program. > "A file that affects the operation of a program" pretty clear cut to > mean exactly the type of files at issue here. I understand that this is not what you want this part of Policy to mean, but a "configuration file" in Policy has always been the file that you edit to change the operation of the program. It is not a *requirement* that every file shipping with the package that contains configuration defaults be installed in /etc. Given the number of packages that hard-code configuration defaults into the binary and put them nowhere else on the file system at all, this would not be possible. It is *common* for a package to install a configuration file that has some or all of the defaults, as a template for local administrators to modify, but there have always been packages that do not do this, and other packages that do this for some configuration files and not others. There have always been some packages that put the defaults or the configuration template elsewhere, whether that be /usr/share/doc/<package>/examples or hard-coded into some binary. Packages that use this "empty default /etc" configuration approach do not ship *any* configuration files under the Policy definition. They only ship binaries and data files for those binaries that contain default settings. Those files are not modifiable and are not configuration files in the Policy sense. From a Policy perspective, they're exactly like the files installed in /usr/share/pam-configs, /usr/share/doc-base, or /usr/share/applications, which are also files that affect the operation of a program. I agree that the wording in Policy could be clearer. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
