Re: Configuration files, local changes, and "managed section" markers
On Tue, 14 Feb 2023 at 19:24, Russ Allbery <rra@debian.org> wrote:
>
> Christoph Biedl <debian.axhn@manchmal.in-ulm.de> 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
> that?
>
> 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:
https://github.com/openSUSE/libeconf
https://tracker.debian.org/pkg/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.
Kind regards,
Luca Boccassi
Reply to: