Discussion on the technical details of using dpkg-divert for configuration
seems to have died down. My basic summary of the discussion is (A) any
system attempting to configure site defaults requires use of dpkg-divert
on conffiles[1], and probably should use dpkg-divert on all configuration
files for uniformity (though for non-conffiles its current effect is a
glorified 'mv') and (B) our dpkg-divert and symlink approach is not
sufficient to handle all possible corner cases involving configuration
files that are managed by maintainer scripts[2].
However, in that discussion, it seemed there was confusion regarding what
problem we are trying to solve and why existing tools can't solve this
problem.
In many large deployments of Debian today, the source of configuration is
the local administrator of the machine, and so systems like debconf
pre-seeding, systemimager, cfengine, and puppet are acceptable
configuration solutions. For configuring many identical machines
administered by the same people, these techniques do provide a reasonable
solution. However, for other deployments, such as the individual desktops
and laptops of students at a university or of the developers at a company,
system administration needs to be distributed in order for important work
to get done efficiently. Our system is designed for changing the default
configuration for those machines, which I've called "site defaults", while
leaving as much control as possible in the hands of the local system
administrator. In particular, our system provides site defaults with the
following desirable properties:
- A machine's local administrator can easily override the site defaults,
using the same mechanisms he had available to configure the system before
our site defaults were installed (including using our configuration
package system).
- Configuration packages support installing the configuration on an
existing machine with an unknown state, and supports distributing updates
to the site-wide configuration using the standard apt-get interface.
- Installing our configuration does not destroy information.
Configuration packages support being uninstalled, restoring the machine to
its configuration before the relevant configuration package was installed
(as has been noted, there are some potential issues with many upgrades
followed by uninstalling the configuration package).
- The marginal effort for supporting additional Debian and Ubuntu releases
from a single source package is low. Our system makes easy applying
regular expressions or other simple transformations to the stock Debian
configuration files, which makes it easy to preserve unrelated upstream
changes in the configuration automatically.
- Our CDBS modules automate things like verifying the md5sums shipped with
upstream conffiles at build time and generating the postinst code that
executes dpkg-divert, taking as input only makefile variables that specify
(e.g.) the list of configuration files to be replaced (and the scripts
that do the transformations).
In achieving these goals, we have sacrificed the ability to handle with
certain small classes of configuration files that cannot be safely
configured using our system. When using our system, someone with Debian
packaging experience needs to inspect the relevant postinst file for a
package being configured and verify that upgrades of that package won't
override our mechanism of dpkg-diverting the configuration file and
replacing it with a symlink to a different file. It seems such problems
are fairly rare (they haven't substantially interfered with our deployment
at MIT), and I'm sure such bugs will become a lot less common if our
system becomes popular.
I have adjusted the documentation on
<http://debathena.mit.edu/config-packages/> to explicitly discuss the fact
that someone needs to read the postinst scripts that generate
configuration files that one is configuring with a configuration package
and verify they are safe to use with this system.
I'm submitting an ITP bug for this package at this time. I am happy to
continue discussing any technical issues related to this configuration
system as the Debian community finds useful.
-Tim Abbott
[1] One could also run an apt repository with modified versions of the
relevant upstream Debian packages with modified configuration files, but
I don't think anyone will argue this is a good solution.
[2] My preferred solution for this general class of problems would be for
packages that manage configuration files via debconf to follow dpkg-divert
when upgrading their configuration file. It potentially requires touching
the 600 or so packages that use debconf (presumably to add a call to some
common function to follow dpkg-divert), but its potential side effects are
reasonably easy to reason about, and it should resolve all of the upgrade
and uninstallation problems with using dpkg-divert on configuration files
managed by debconf (though this leaves open correct behavior when someone
runs dpkg-reconfigure on such a system)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
