[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian Configuration Packaging System

On Tue, 26 Feb 2008, Frank K├╝ster wrote:

3) Scripts that are not marked as conffiles but which cannot be configured in any way other than by modifying the script.

If those scripts live below /etc, they definitely should be marked as conffiles. If they live elsewhere, no package should edit them.

I think it's totally reasonable for the MIT site configuration packages to (e.g.) divert chsh to replace it with a wrapper that supports handling both inherently local user accounts (like root or postfix) by calling chsh.debathena-orig and network accounts (through some other mechanism). While some might argue that instead MIT should create a modified version of the passwd package to make this change, I think our solution is substantially cleaner.

It's important to keep in mind is that while the system for creating configuration packages should be part of Debian, the configuration packages themselves are not distributed as part of Debian, but should instead be considered as modifications to Debian. It makes sense for them to be able to change some standard programs in a way that only makes sense for that particular site, but doesn't break other uses of those programs, as well as changing configuration file defaults.

One idea [...]
would be for dpkg to run postinst scripts in a special environment that
rewrites filenames according to the diversion database

I would rather contemplate a new interface for configuration packages, something
like a hook which has to be executed by each postinst script and allows the
configuration package to bring its settings into effect. If you want to be able

Would deploying this new interface require modifying every Debian package's postinst scripts to add support for this new hook? I'm not enthusiastic about the deployment costs of that kind of sweeping change if there are more localized changes to Debian that would work.

to remove configuration packages, the original file needs to be preserved
somehow, but the current dpkg-divert is not sufficient for this:

Consider someone installing the configuration package in stable+0, then
upgrading to stable+1 and keeping it, and then upgrading to stable+2 and
subsequently removing the configuration package. Any special code in the
maintainer scripts which dealt with incompatible conf(iguration )file changes in
the stable-to-stable+1 upgrade is likely to have been removed by now, so the
old, incompatible, file from stable+0 will be used after the removal, and the
package is in a broken state.

That's certainly a potential problem with our current system.

The "filename rewriting" idea does not have this problem. During the upgrades, the maintainer scripts for the package would update /etc/ldap/ldap.conf.debathena-orig (rather than the running version), and when the configuration package is uninstalled, /etc/ldap/ldap.conf.debathena-orig will be moved back to /etc/ldap/ldap.conf, leaving the package in the state it would have been in had the configuration package never been installed in the first place.

The "filename rewriting" plan is really a natural extension to the current dpkg-divert behavior; rather than just unpacking files in locations as determined by the diversion database, all actions by the packaging system would have their filenames transformed according to the diversion database. I also can't think of anything that doing this would break -- its primary cost would be the added complexity in dpkg (and perhaps some performance penalty, depending on implementation).

But it's also no silver bullet. There are packages that want to restart their daemon after changing their configuration file, and it's unclear to me how to prevent packages from restarting their daemon (or regerating their database, etc.) in the "filename rewriting" environment.

	-Tim Abbott

Reply to: