Re: Debian Configuration Packaging System
Timothy G Abbott <tabbott <at> MIT.EDU> writes:
> On Mon, 25 Feb 2008, Frank Küster wrote:
> > Uh, you can dpkg-divert conffiles, but not generally configuration files,
> > since many won't even be known to dpkg. I must admit I'm a bit sceptical
> > about a proposal on configuration, written by someone who lets this
> > important distinction slip by...
> No, I really meant configuration files. While our system certainly
> applies to all conffiles, it also applies to various other classes of
But in these cases you can't use dpkg-divert.
> 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 probably should have said this explicitly earlier, but our system is
> currently only an 80% solution, because it cannot override any package's
> configuration file handling system that does not preserve manual changes.
Such a package has a RC bug anyway.
> It turns out that these are fairly rare, and can be handled with some
> annoyance (e.g. releasing a new version of our configuration package
> whenever a new release of such a package comes out, so that the
> configuration package wins).
Of file a bug...
> So, yes, our system uses both symlinks and dpkg-divert.
Ah, I understand. I think here you have a much larger problem than with the
small number of RC-buggy packages that don't keep manual changes: Larger because
I fear there are more packages with such problems, because less people are aware
that it is a problem, and maybe even because there might be some debate whether
respecting a symlink state actually is required by policy.
> 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
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.