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