debconf vs. the sysadmin
(This topic has previously been discussed in a long thread titled "the
art of debconf" and "more debconf queries back in late April, but there
didn't seem to be any satisfactory conclusion, so I'm hoping people have
gotten smarter in the meantime. :-))
The "normal" sequence for a basic configuration file using package, as I
understand it, is as follows:
On a new install:
1. The config script asks questions, and stores the answers in the db.
2. The postinst (with arg "configure") retrieves the answers from the db
and writes the configuration file.
Well and good, but now we are stuck:
A. If the postinst doesn't check for the non-existance of the
configuration file before writing the new one, then when the package is
upgraded, we run the risk of overwriting changes made outside of debconf
(e.g. sysadmin edited the file).
B. If the postinst *does* check, then dpkg-reconfigure doesn't work
(with no warning).
Proposed (off of the top of my head) solutions:
I. Make dpkg-reconfigure call the postinst with a different
argument. This assumes that if the sysadmin uses dpkg-reconfigure, then
hie expects to over-write any manual changes.
II. Create a dynamic equivalent to the conffile mechanism, so that
the maintainer can register an md5sum for the configuration file
(with debconf? something else?) which would be updated only when the
configuration file is changed by the postinst. Then the postinst could
compare the current md5sum with the stored value and only update the
configuration file if they were the same. This has the downside of
basically eliminating the use of dpkg-reconfigure after a manual change.
(Yes, I could hack something like this together for my packages, but it
would be much better to have a standard mechanism.)
We need to come up with some way to deal with this issue, or admit
that debconf is only useful and should only be used on initial package
install.
Steve
Reply to: