dpkg-reconfigure, policy, and least surprise principle

[Roland Mas <lolando@debian.org>]

  Hi all,

  I'm confronted with a problem here, and I'd like your valuable
advice.  I suppose this problem has occurred before, but no obvious
references to it are in the policy, or in the Debconf documentation.

  I have a package (let's call it sourceforge) that uses Debconf to
ask a few questions at install time, and writes the results in a file
in /etc/sourceforge/sourceforge.conf.  There is a sourceforge-config
script to turn this "master" config file into a set of Perl, PHP and
Apache configuration files.  According to policy, the postinst script
does not overwrite local configuration: it only adds missing values to
the sourceforge.conf file, and does not overwrite the ones already
present.  Upgrade thus does not overwrite local settings, and all is
well.

  Except...  Except when some user types "dpkg-reconfigure
sourceforge".  He then changes some values in Debconf, and the
postinst is re-run like it would be for an upgrade.  In other words:
the new values typed in debconf are not used in the master
configuration file, and obviously not transferred to the other files.
The user is then greatly perplexed.

  On the one hand, I am not allowed to change sourceforge.conf on
upgrade, and on the other hand the user expects a dpkg-reconfigure to
really reconfigure his system.  Yet both operations do the same thing
(invoke postinst).  What to do?

  A hypothetical third hand would be holding this: the postinst first
reads the master config file and shoves its values into Debconf, then
asks the debconf questions, then updates the sourceforge.conf file
with the new values from Debconf.  It sounds horribly messy, though,
and I'm not sure it's doable without too much hackery.

  Anyone got a fourth hand?  Please?

Roland.
-- 
Roland Mas

Using a big hammer without caution can cause big damage.
  -- PostgreSQL documentation, chapter 42