Henrique de Moraes Holschuh wrote:
> Please document this, it may save someone a grave bug someday, and maybe
> even avoid a lot of headaches.
Does it really need to be documented in policy? debconf-devel(8)
documents it:
The config script can be run in one of three ways:
1 If a package is pre-configured, with dpkg-precon
figure, its config script is run, and is passed the
parameters "configure", and installed-version.
2 When a package's postinst is run, debconf will try
to run the config script then too, and it will be
passed the same parameters it was passed when it is
pre-configured. This is necessary because the pack
age might not have been pre-configured, and the
config script still needs to get a chance to run.
See HACKS for details.
3 If a package is reconfigured, with dpkg-reconfig
ure, its config script it run, and is passed the
parameters "reconfigure" and installed-version.
Note that since a typical package install or upgrade using
apt runs steps 1 and 3, the config script will typically
be run twice. It should do nothing the second time (to ask
questions twice in a row is annoying), and it should defi
nitely be idempotent. Luckily, debconf avoids repeating
questions by default, so this is generally easy to accom
plish.
...
HACKS
Debconf is currently not fully integrated into dpkg (but I
want to change this in the future), and so some messy
hacks are currently called for.
The worst of these involves getting the config script to
run. The way that works now is the config script will be
run when the package is pre-configured. Then, when the
postinst script runs, it starts up debconf again. Debconf
notices it is being used by the postinst script, and so it
goes off and runs the config script. This can only work if
your postinst loads up one of the debconf libraries
though, so postinsts always have to take care to do that.
We hope to address this later by adding explicit support
to dpkg for debconf.
(This man page will be in the next release of debconf BTW.)
--
see shy jo
