Marc Haber <mh+debian-de...@zugschlus.de> writes: > The issue is, however, a lot more complicated than one would might > think, imagine a structured configuration file like a systemd unit or an > icinga or bind or ISC DHCP config file which would need multiple > "managed sections", and the special case of a setting moving from > managed to non-managed in the package or at the local admin's > discretion.
I had that sort of configuration file in mind when I was talking about include, but I guess it depends on what sort of settings one expects to be managed. I can think of a few possibilities, all of which include handles okay (complicated configuration that people can selectively override but where we don't want to treat the whole thing as a configuration file, a small Debian-generated group of settings that should be included in a larger conffile, or a bunch of completely static configuration that no one should ever change although that last case is weird). Yes, nested structure is a bit complicated but in the examples you list surely there isn't very much configuration that should be inaccessible to the local admin? Since that's what's implied by having it *not* be in a managed section. > <---rant---> > On the other hand, putting non-changing configuration in /usr reminds > me of the systemd way to handle things, with a complicated combination > of "if an identically named file is in /etc, it overrides the > package-delivered configuration entirely without the local admin > noticing that there was an upstream change" and "put configuration > snippets in a magic place in /etc and it will augment the > package-delivered configuration without the local admin notiting that > the upstram changed in a way that is incompatible with the local > augumentation". This way to handle things was of course invented in > the Red Hat world because rpm's conffile handling is so vastly > inferior to what we have available for 25 years now, and sadly we have > taken this over 1:1 into Debian, not making use of your vastly > superior methods here in favor of being compatible with Red Hat's > worse solution. > </---rant---> Well, I adore this way of configuring things and think it's way better than how Debian has been doing it and I haven't used Red Hat since the late 1990s, so *shrug*. :) But the point wasn't to advocate for that approach specifically, only that if you *do* have configuration that the user is not allowed to change because the package is going to override it, it needs to not be in /etc, because if it's in /etc it's going to be really confusing. I don't care where you put it, but /usr is the logical spot? I think your argument is that maybe you shouldn't have a bunch of configuration the user can't change, and I agree! -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
