TurnKey Linux's take on Ubuntu appliance development: KISS
forest at alittletooquiet.net
Thu Jan 7 20:32:28 GMT 2010
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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20100107/5a562ce0/attachment.pgp
More information about the ubuntu-devel