Looking at the output of debconf-get-selections and the
preset values shown by dpkg-reconfigure it seems to me
that sometimes they do not match. Example: If I change
the database for mdadm using

echo -e "mdadm\tmdadm/mail_to\tstring\tmonitoring@example.com" | debconf-set-selections
debconf-get-selections | grep ^mdadm

then I can see the new value in the output of debconf-\
get-selections, but dpkg-reconfigure still uses the old
value.

Seems that there are 2 databases. This is confusing and
unexpected. How can I change the real one for a non-
interactive reconfiguration?

This problem is not restricted to mdadm. exim4-config
doesn't play nice, either. I am sure there are more.


Regards
Harri

Harald Dunkel wrote:

There are not 2 databases.

It's up to individual packages how they deal with debconf settings.
In general, the current configuration of the system is preferred over
what is in the debconf cache when reconfiguring a package. It's often
considered a bug if a package uses some, possibly old value from the
debconf cache and blows away local admin changes to the system.

Debconf preseeding is not really intended to be used with dpkg-reconfigure,
but instead to be done before a package is installed for the first time.

I understand. Maybe I am too blind to see, but this is completely
left out in debconf(1) and others, i.e. the "confusing and unex-
pected" still stands.

Maybe it would help to extend the Debian policy to make sure that
packages do not ignore their own(!) options stored in the debconf
database? Just for using debconf, of course.

debconf-set-selections(1):

"debconf-set-selections can be used to pre-seed the debconf data-
base with answers, or to change answers in the database. Each
question will be marked as seen to prevent debconf from asking the
question interactively.

WARNING
Only use this command to seed debconf values for packages that will
be or are installed. Otherwise you can end up with values in the
database for uninstalled packages that will not go away ..."

No word about "first time install only".

Some real-life packages simply behave differently to what is des-
cribed in the man page, even though they are using debconf. This
doesn't seem right.


Regards
Harri