Re: Configuration files, local changes, and "managed section" markers
Marc Haber <mh+debian-devel@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: