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
