Updating configuration files

[Scott Kitterman]

On Wednesday, February 09, 2011 10:12:12 pm Ted Gould wrote:
> On Wed, 2011-02-09 at 11:13 -0800, Steve Langasek wrote:
> > On Wed, Feb 09, 2011 at 09:22:16AM -0500, Barry Warsaw wrote:
> > > There's one thing I miss from my days running Gentoo, and no, it's not
> > > the unholy number of hours it takes to upgrade due to recompiles. :)
> > > 
> > > When a system configuration file gets updated, emerge gives you a
> > > richer set of options for dealing with changes.  I'm reminded of this
> > > with the just upgraded ntp package, which modifies /etc/ntp.conf.
> > > 
> > > Debian/Ubuntu gives you the option to:
> > > 
> > > * Keep your version
> > > * Install the new maintainers version
> > > * See the diff
> > > * Drop into a shell to "deal with" the situation
> > > 
> > > I think these are insufficient.  What I really want to do is merge my
> > > local changes with the new package version, and I'd like the tool to
> > > help me do it.
> > > 
> > > emerge gives me several other options.  It's been ages since I ran
> > > Gentoo so I don't remember all the details, but one other option was
> > > extremely helpful:
> > > 
> > > * Interactively merge local changes with the new version of the config
> > > * file
> > 
> > So these days, there are three major paradigms used for configuration
> > file management within Debian packages.
> > 
> >  - conffiles - this is the built-in dpkg prompt you refer to, with the
> >  
> >    incomplete set of choices.  Really, this is only a suitable mechanism
> >    for configuration files that will rarely, *if ever*, need to be
> >    changed by either the local admin or the package maintainer.
> >  
> >  - templates spit out by maintainer scripts - this avoids the annoying
> >  
> >    prompts, but also generally doesn't give the admin very much support
> >    for updating to new package defaults because the maintainer doesn't
> >    go to the effort of manually merging the changes in.
> >  
> >  - ucf.  This option *does* store the original version of the file on
> >  disk
> >  
> >    in order to support a three-way merge, which makes it possible to
> >    offer better options on upgrade.  Not quite the same as an
> >    interactive merge, but an interactive merge option could be added
> >    here without too much extra work.
> > 
> > This last is the one is the way to go, but it really should be pulled
> > into dpkg itself.  I don't recall if Sean's patches were based on ucf or
> > not.  In the meantime, use of ucf requires explicit action by the
> > package maintainer, so it's generally only the real problem children
> > that get converted over to its use.
> 
> I guess the fourth that I see in use is having a directory of files that
> are loaded to build the configuration file.  Honestly, this is the one
> that I prefer most of the time as it means that the base file always
> upgrades.  For sure, this doesn't work for all files, but it seems like
> if effort is going into configuration files it would be worth converting
> all that can to the directory method.

Some packages already do this.  See amavisd-new as an example.

Scott K