Hey list,Hi,
[...]
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.
[...]
(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.
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.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 285 |
Nodes: | 16 (2 / 14) |
Uptime: | 64:21:17 |
Calls: | 6,488 |
Calls today: | 1 |
Files: | 12,096 |
Messages: | 5,274,794 |