Hello,
Perhaps I'm just too timid for a bug report against debconf-doc but at
the moment there are too many things I haven't fully understood yet.
Basic problem: A daemon, started as usual via /etc/init.d/daemon, and
it gets additional parameters via a config file /etc/default/daemon. The
system administrator should be able to configure that information
during installation, i.e. debconf.
After reading debconf-devel(7) several questions remained.
* "config" sample
The given "config" file sources $CONFIGFILE if present but asserts
FOO and BAR are defined there. Is this safe? I'd rather wipe out any
pre-existing values:
# Load config file, if it exists.
if [ -e $CONFIGFILE ]; then
+ FOO=
+ BAR=
. $CONFIGFILE || true
# Store values from config file into
# debconf db.
db_set mypackage/foo "$FOO"
db_set mypackage/bar "$BAR"
fi
On a side note, the same holds for virtually every init script that
sources a config file.
* "postinst" sample
If I understand correctly, all the logic shown applies only for the
"configure" invocation. Or did I miss something? Therefore the
sample should be embedded in a switch like
#!/bin/sh
case "$1" in
configure)
# code as in debconf-devel(7) here
CONFIGFILE=/etc/foo.conf
set -e
. /usr/share/debconf/confmodule
(...)
mv -f $CONFIGFILE.tmp $CONFIGFILE
# end of code as in debconf-devel(7)
;;
abort-upgrade|abort-remove|abort-deconfigure)
# other cases here
;;
(...)
esac
This would have helped my understanding a lot.
* config file default values
It is quite common to ship a /etc/default/daemon in the package.
However, this leads to the situation that default values are stored in
three different locations:
* debian/default as set up by the maintainer
* debian/template for debconf
* debian/postinst where the file is created if missing
I doubt this is the best solution.
* Which "config" script is the good one?
debconf-devel(7) presents two "config" scripts. The first in "Config
file handling" with, as the name says, proper handling of a config
file. The second, way better in its capabilities, in "Letting the
user back up" but without config file handling. This leaves me in the
unhappy situation a really useful example is still missing. Of course
I can merge both but leaving this task to the developer is not a
good solution.
* Putting everything together
I feel the whole process isn't as comfortable as it could be. The
"config" part always will always remain handwork since only the
maintainer knows about the interdependencies of the variables and
where and how to back up. But the "postinst" part looks like it could
be automated entirely. All information such a program needs is the
name of the config file and a mapping between the debconf and the
shell variables. Such a program could also add missing variables
in a more sophisticated way that sed does, i.e. detect a setting
commented out and place the definition there. And it would create a
new config file only if required.
Comments? Corrections?
Christoph
Attachment:
signature.asc
Description: Digital signature