TurnKey Linux's take on Ubuntu appliance development: KISS

[Forest Bond]

Hi Evan,

On Thu, Jan 07, 2010 at 02:19:34PM -0600, Evan Broder wrote:
> On Thu, Jan 7, 2010 at 1:50 PM, Forest Bond <forest at alittletooquiet.net> wrote:
> > 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.
> 
> 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.

This sound like the right way to handle this situation.  Thanks for the pointer.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100107/5a562ce0/attachment.pgp