Re: preferred method for coexistence of debconf- and manual parts in conffiles?
On Wed, Nov 05, 2003 at 03:03:24PM +0100, Frank Küster wrote:
> if a package wants to use debconf to manage a configuration file, but
> still let the user have the option to manually add entries - is there a
> preferred way how to do this?
Have you read debconf-devel(7), namely the section on "Config file
handling"? If not, do.
> Put the information from the debconf database into the file, but between
> markers ### begin DEBCONF section for $package... ### end DEBCONF
> section for $package. So an admin can add his customization before or
> after that, and upon dpkg-reconfigure or an upgrade only the part
> between the markers will be changed.
> Is this concept o.k.? I couldn't find anything in the policy about that.
I dislike "debconf sections". It should be possible for the sysadmin to
edit whatever he/she likes under /etc without having to learn about
strange automatic configurator tools with which they may well be
> Here's why I come to ask the question: Recently, a bug was filed against
> tetex-bin, #209395, criticizing that a configuration file, language.dat,
> is not in /etc, but under /var.
Yeuch, tetex is the most disastrous example of configuration file
handling I can think of. I keep being repeatedly asked strange questions
about merging configuration files I know for certain I've never touched,
and asked incomprehensible debconf questions about files I don't care
> He should have answered "no" to the question wether debconf should
> manage this file if he wants to do that.
I have to say that I'm coming to believe that anything that talks about
"debconf managing this file" is a bug. If the user makes changes to the
file, I think it's the package's responsibility to cope with that. A
three-way diff or something would be fine if it's too difficult to merge
the changes automatically.
(Also, it's horribly sloppy wording. debconf is just providing the means
to ask the user questions, while *your package* is managing the file. As
a result, lots of people blame debconf for bugs that are the fault of
individual packages, which gives debconf a bad name.)
Colin Watson [firstname.lastname@example.org]