Re: Configuration files, local changes, and "managed section" markers
On Tue, 14 Feb 2023 at 19:24, Russ Allbery <email@example.com> wrote:
> Christoph Biedl <firstname.lastname@example.org> writes:
> > these days, I found a package in Debian (four-digit popcon count) that
> > in an upgrade happily removed some some changes I had made to a
> > configuration file of that package, in /etc/.
> > My immediate reaction was to consider this a gross violation of the
> > Debian Policy (10.7.3 "Behaviour"). Upon closer inspection however I
> > found there are markers in that file that define a "managed section", an
> > area where the upgrade process wants to do things - local modification
> > ought to be placed outside of that, they will not be harmed, then. FWIW,
> > this functionality was implemented upstream.
> Policy is fairly explicit that you can't do that, but I suspect we do this
> in other places as well because some very natural patterns for debconf
> prompting (load default answers from a file, ask some questions, write out
> a file containing the answers) tend to cause the same thing if someone
> puts other unexpected settings in the same file.
> 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'm guessing that we're working around upstream limitations here, but if
> upstream's configuration file syntax supports some sort of include
> directive, that's ideal, and if it doesn't, maybe there's some way to add
> 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.
If any code changes to handle configuration are done, the absolute
best thing is to just switch upstream to use libeconf:
This automatically does the right, modern and expected thing and works
in the same way across all distributions, removing the need to carry
any downstream technical debt.