On Tue, 26 Feb 2008, Ian Jackson wrote:
Tim Abbott writes ("Re: Debian Configuration Packaging System"):
applying dpkg-divert to configuration files.
Yikes.
At the moment, there are no choices for doing site configuration that are
general enough to change arbitrary configuration options and don't destroy
whatever configuration state the machine had before configuring it (as
well as suffering from a version of every bad interaction with existing
maintainer scripts that our system has).
All of the important problems with our dpkg-divert based configuration
package system that have been discussed in this forum are problems for any
configuration mechanism other than debconf preseeding. Debconf preseeding
is unacceptable for site configuration because it is insufficiently
general (often things need to be configured that are not set up as debconf
options).
Any system that is not based on debconf pre-seeding (or maintaining a fork
of all the relevant packages containing the relevant configuration files,
which is unmaintainable) will have all the problems with maintainer
scripts that our system has. Further, any configuration system that does
not use dpkg-divert will have to fight with dpkg over control of conffiles
(a problem that our system does not have).
It turns out that our system also works for almost all the other
configuration files that we've wanted to change (in particular, those
whose packages don't overwrite manual changes with answers from the
debconf database on package upgrades, something the Debian Policy Manual
forbids anyway).
So, anything attempting to achieve the functionality we want has to use
dpkg-divert, and I think the best way to remove the problems with dealing
with configuration files that are not conffiles should probably involve
making maintainer scripts that do overwrite existing configuration files
follow diversions when doing so (though one mechanism or another).
Tim Abbott writes ("Re: Debian Configuration Packaging System"):
I'll note that we wrap our dpkg-divert calls with a bunch of
error-handling code that we found quite important for correctly recovering
from people hitting ^C in the middle of installation (see
<http://debathena.mit.edu/config-packages/code/config-package-dev-4.2/divert.sh.in>
for the code). Earlier iterations that did not do this were plagued with
problems whenever there were errors in installation.
Yikes.
Those earlier iterations date to 2004 and were never deployed beyond a
testing environment. The particular shell code we're using now has been
basically unchanged since we wrote it back in Summer 2006, and has not
been a problem for us since.
-Tim Abbott
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
