Re: Configuration file handling (Re: [desktop] Unix configuration nightmare)

[Matt Zimmerman <mdz@debian.org>]

So I got to prototyping this, just to play around with it and see what
worked.  Then I was reading a thread on debian-mentors about Apache
configuration, and I remembered how much of a pain that is currently.  It
occurred to me that a merging system could perhaps be used to make this
sane.  I'd like to think about this a bit and see if it affects any design
decisions, so that this could be supported in the future at least.  The
basic idea would be for the package to modify a copy of the saved config
file, rather than basing its modifications on the installed file.  Example:

- Package P wants to add a stanza to /etc/shared.conf
- P asks for a copy of /etc/shared.conf to modify; we give it the installed
  copy
- P makes its modifications and provides the resulting config file
- We present the result as a proposed config file merge, as in the simple
  case discussed in previous messages in this thread
- We store /etc/shared.conf as the "last known" revision for P
- we apply the changes

...time passes...

- A new version of package P comes along and wants to apply the same changes
  to /etc/shared.conf, not knowing if they are already present
- P asks for a copy of /etc/shared.conf to modify, we give it the "last
  known" revision
- P finds its changes already present, and no changes are made

...time passes, the admin decides he needs to change something that was
added by P, and does so...

- A new version of package P is installed. the above scenario repeats; it
  knows that it has already added its changes, without regard for whether
  they are actually present in the current /etc/shared.conf.  The admin's
  changes are preserved, and disaster averted.

...time passes, and package P's needs change...

- A new version of package P needs to make a different change to
  /etc/shared.conf, perhaps even one overlapping with the old change
- P asks for the "last known" revision of /etc/shared.conf, applies its
  changes
- We attempt to merge those changes into /etc/shared.conf.  If they do not
  overlap with the admin's changes, then we present the result as a merge.
  If they do overlap, then a conflict results, and we resolve it as for the
  usual case.
- We apply the changes requested by P to the "last known" revision,
  indicating that they have been resolved.  Future releases of P find their
  changes already applied, and are satisfied.

Similar actions would take place independently for each package which
modifies the configuration file.  Each package would be modifying its own
view of the config file as it last saw it, and the changes merged into the
installed version.  Each new change made by the package only needs to be
resolved once

This scheme would provide for shared configuration files with the same user
experience as configuration files which are owned by a single package.  The
only implementation detail is that we keep track of a separate revision of
the config file for each package which modifies it.  This does not seem like
a high price to pay.

This leads into a continuation of the question of how to store these files.
Warn me now if using RCS in this application would bother you, because it's
starting to look like it might be a good fit.

-- 
 - mdz