Re: Configuration files, local changes, and "managed section" markers
Marc Haber wrote:
> On Tue, 14 Feb 2023 11:23:55 -0800, Russ Allbery <email@example.com> 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.
Half-conffiles like that prove *really* difficult to work with in other
A half-conffile causes many problems when trying to track /etc in git,
And a half-conffile (or a single full-conffile with no .d directory) is
more difficult to work with when the admin wants to make programmatic
changes of their own. For instance, if you want to package up your
configuration in a .deb package to install on multiple systems, you can
do that more easily if the software you're configuring handles .d files
or similar, rather than *only* supporting one big configuration file
that you have to edit.
For that and various other reasons, I'm very happy with the trend
towards "you can override package configuration in /usr with local
configuration in /etc by creating a file of the same name".
But that said, I absolutely think Debian can improve further on that
design and tooling. For instance, I'd love to see ucf-style support for
noticing "You're currently overriding /etc/foo.d/thing.conf, and
a new version of the package just shipped a new /usr/share/foo.d/conf,
would you like to review the changes and figure out if you want to