Re: Configuration files, local changes, and "managed section" markers
On Tue, 14 Feb 2023 11:23:55 -0800, Russ Allbery <rra@debian.org>
wrote:
>I think the right answer (which as is often the case involves a lot more
>work) is to break the configuration file into separate parts, one of which
>is a true configuration file in the Policy definition and the other of
>which is the settings that are needed by the upstream software but that
>aren't a configuration file in the Debian sense (and thus aren't
>user-modifiable), put the latter in /usr, and convince the program to load
>them both in some way.
I must say that I really like the idea of having "managed sections",
allowing half-conffiles which is much easier to handle for non-complex
cases where configuration is just a few lines and which would appear
overly complex if we'd split that into conffile and non-conffile.
The "split it" approach is something that comes naturally to someone
who has been heavily socialized in the Debian Universe because we
handle conffiles on a file level. It feels unnatural and clumsy for
someone who is not familiar with the deep historic reasons for us to
do it like that.
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.
<---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--->
>If the right fix isn't available, I would be tempted to convert the whole
>configuration handling to ucf or something similar that has built-in
>functionality to try to handle cases like this.
ucf is actually what dpkg should have been, I'd recommend it
wholeheartedly, but we need more automation for that.
Debian's way to handle conffiles is the best the Linux world has. That
doesn't mean that we don't have room to improve. And sadly, we haven't
moved a single inch here in 15 years.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Reply to: