Brian Nelson wrote: > I have a prospective package that checks for the environment variable > DPKG_RECONFIGURE=1 in the postinst, and if it decides that it's being > reconfigured, it will overwrite its configuration file (not a conffile) > based on the debconf answers. The theory is that if a user reconfigures > a package using dpkg-reconfigure, he most likely will want to generate a > new configuration file. The old file is backed up, of course. > Otherwise the postinst script will leave the file alone. > > My sponsor told me that he thought he recalled you previously mentioning > that you frowned upon this sort of hackery, and that I should check with > you. > > Unfortunately, this is one of those configuration files that is > difficult to parse, so I'm not sure how else to handle the file in > postinst. I'd really prefer to avoid a situation where the file is > either absolutely managed by debconf or not at all, or a file with a > "hands-off" section that the user isn't allowed to touch. > > I think the optimal solution would be this one brought up by Matt > Zimmerman recently: > > http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg01533.html > > but I'm not sure what to do until that gets implemented.
The environment variable is DEBCONF_RECONFIGURE, not DPKG_RECONFIGURE, and if you check it you should also check for $1 = reconfigure, for forward compatability as described in debconf-devel(7). I have fewer qualms about a package that only wipes out a config file when explicitly reconfigured; most of my ire is reserved for packages, like apt-listchanges, that drop local modifications to such files on upgrade. Especially when the files are (as in the case of listchanges.conf) trivial to parse and modify without loss. If your files is really really hard to parse & modify losslessly then letting the user blow it away by reconfiguring is ok. -- see shy jo
pgpWPR5nZc55n.pgp
Description: PGP signature
