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
