The art of debconf

[John Goerzen <jgoerzen@complete.org>]

Hi,

I am starting to work with debconf.  I have read its manuals, which are
clear enough about it, but I have some questions about how it integrates
with the rest of the system.  I really like the idea and want to commend
Joey, Wichert, and everyone else involved with it for their work.  However,
I do have some questions.  Maybe there are no easy answers to these, or
maybe I'm missing something obvious.  In any case, insight into how others
are dealing with these issues would be highly appreciated.

For the packages I will be discussing, assume a package with a complex and
capable configuration file format -- one with which the user will use a
debconf method to configure only a few basic parameters, and which does not
already have its own template system.  Examples of such a package might
include listar, postfix, etc.

Now, here is the question.  What is the best way to handle a situation where
a user might both edit the file and use debconf to edit it?  One solution
that springs to mind immediately is templates.  But this is ugly, forcing
the user to run a utility to generate the real file is messy and templates
are annoying to keep up with anyway.

We could just pretend the whole issue doesn't exist, and force the user to
either edit the file by hand or use debconf to edit it.  This doesn't sound
very reasonable either.

Or our debconf scripts could (attempt to) parse the file.  I haven't found
any which really do this, though.  lynx makes a very half-hearted attempt to
do it, but I note that the lynx package does not even work with
dpkg-reconfigure!  Plus, having shell or perl code to reparse conffiles
doesn't seem like a good usage of programmer's resources.

Finally, what happens if a person manually tweaks debconf-controlled values
in a conffile?  Do the manual values take precedence for defaults, or does
the debconf database?  If the former, is there really a need for a database? 
If the latter, do we warn the user?

Thanks!

-- John Goerzen