Re: Wrestling with debconf

[Niels Thykier <niels@thykier.net>]

Kip Warner:
> Hey list,
> 
> [...]
> The problem here is this re-running of the myfoo-server.config happens
> before the myfoo-server.postinst. This is bad because the latter is
> supposed to update the values in /etc/myfoo/server.conf to whatever the
> user just entered via debconf prompts.
> 
> Because myfoo-server.config's second invocation sees the newly unpacked
> /etc/myfoo/server.conf, it unintentionally seeds debconf with the
> values contained therein.
> 
> [...]
Hi,

(Having seen your enquiry on IRC, I presume this issue was still relevant)

I read the "newly unpacked /etc/myfoo/server.conf" as you shipping
"/etc/myfoo/server.conf" directly inside the package in that path.  If
that is correctly understood, then I think that is the source of your woes.

As I recall, when you manage a file via debconf, you should *not* ship
it directly in the package.  You can ship a template in a different
location (e.g., /usr/share/myfoo/server.conf.template) and then use that
combined with the debconf answers to generate the initial
/etc/myfoo/server.conf.

Perhaps have a look at openssh-server (postinst + config + file listing)
as an example, which does something similar.  It does use "ucf" for
handling the merge on updates, which is a different approach than yours
for creating/updating the configuration file.
  I can recommend that from a consistency PoV, so your package would
behave the same as other Debian packages if the user were to change the
file directly.  However, I do not think it would be strictly necessary
to migrate to ucf in order to fix your immediate issue.

I hope that helps.

Thanks,
~Niels