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)

with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to