TurnKey Linux's take on Ubuntu appliance development: KISS

[Evan Broder]

On Thu, Jan 7, 2010 at 1:50 PM, Forest Bond <forest at alittletooquiet.net> wrote:
> Hi,
>
> On Thu, Jan 07, 2010 at 05:23:36PM +0100, Soren Hansen wrote:
>> On Thu, Jan 07, 2010 at 01:00:08PM +0100, Pau Garcia i Quiles wrote:
>> > I'd say the Debian Policy was never meant for the "building a turn-key
>> > appliance"-case. Maybe an amendment is needed: "no package should
>> > modify conffiles installed by other packages" -> "no package should
>> > modify conffiles installed by other packages, except in the case the
>> > package which modifies other packages conffiles states clearly it will
>> > do that in its description"
>>
>> You're missing the point. If you are a novice user, using some tool to
>> make some changes to a configuration file managed by dpkg (i.e. a
>> conffile), upon upgrading said package, dpkg will prompt about changes
>> the user did not make (the aforementioned tool did it on your behalf) to
>> a file the user has likely never heard of. This is obviously not
>> acceptable.
>>
>> If this behaviour is not wanted, it's simple to make sure a
>> configuration file is not considered a conffile.
>
> But this discussion is focused on modifying conffiles from *other* packages.
> (package B modifies package A's conffiles).  Is there some means by which a
> conffile from another package can be deregistered as a conffile?
>
> I suppose the package that plans on modifying it could deregister it and make a
> backup on configure, and then reregister it and restore the backup on purge.
>
> -Forest

At MIT we actually developed a system for one package modifying
conffiles provided by other packages as part of our project to port
the Athena platform to Debian and Ubuntu in a Debian Policy-compliant
way.

config-package-dev (http://debathena.mit.edu/config-packages) uses
dpkg-divert to move the original package out of the way, and then
symlinks the configuration package-provided file into place.

i.e. if you're configuring /etc/nsswitch.conf, a package using
config-package-dev will install an /etc/nsswitch.conf.debathena file,
divert the original /etc/nsswitch.conf to
/etc/nsswitch.conf.debathena-orig in its postinst, and symlink
/etc/nsswitch.conf -> /etc/nsswitch.conf.debathena.

We've found that this has a bunch of advantages:

 - We never touch the configuration that was there before. If our
packages are uninstalled, the uninstall cleanly and revert the
configuration to exactly what it was before we got involved.

 - Because the resulting configuration files are calculated at build
time, not install time, changes that were previously made by the
sysadmin can't have potentially disastrous interactions with our
configuration changes.

We've been using this system for a few years now, and our packages are
now deployed on over a thousand machines. config-package-dev has made
it easy for us to serve a large, heterogenous population, including
support for multiple Debian and Ubuntu releases simultaneously.

(It's sort of secondary to this discussion, but config-package-dev
also has an awesome mechanism for expressing our configuration files
in terms of the upstream default configuration files. We write a
simple Perl script to transform configuration files from upstream to
ours. This is a huge part of what lets us support multiple releases
relatively painlessly, because when we want to bring up support for a
new release, we don't have to update all of our configuration files
for the new release.)

- Evan