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
