best practice for upgrading config files?

Igor Peshansky
Tue May 9 20:50:00 GMT 2006

On Tue, 9 May 2006, Andrew Schulman wrote:

> I'm packaging a new release of lftp.  The default config file
> (/etc/lftp.conf) is slightly different from the one in the previous
> release. This raises a problem:  how should I determine whether to
> replace the old config file?  There are at least three approaches, in
> increasing order of complexity:
> (1) Copy the new default config in only if none already exists:
> [ -e /etc/lftp.conf ] || cp /etc/defaults/etc/lftp.conf /etc
> I've used this approach in my other packages, e.g. orpie.  Gerrit, I
> think it was, told me it was a bug, but looking around I see that some
> other packages also use it.  It's simple, but anyone who's ever
> installed lftp before won't get the new default config file.

This is not a bug, but is a bit inconvenient.  See below.

> (2) Ask the user what they want to do, if /etc/lftp.conf already exists.
> It seems to me that this could get to be quite elaborate; if I'm going
> to ask the user what they want to do, then I need to offer them some
> good alternatives, e.g. look at the diffs.  If this is the preferred
> method for Cygwin, then I shouldn't be writing it ad hoc.  We should
> develop a standard postinstall script or shell function to handle it.

Interactive postinstall scripts are not something we currently support (or
intend to, AFAIK).  If the user has modified the default configuration,
she most likely knows what she is doing, and probably wouldn't want the
installation to muck with her changes (not even if we could create diffs
with the previous version and cleanly apply the patch).  What would be
nice in this case, though, is some feedback like "Not replacing config
file /etc/lftp.conf due to user changes" to the postinstall script's
stdout, which will end up in the setup.log file.

> (3) Compute a checksum of the current /etc/lftp.conf, and compare it to
> the checksum of the old default.  If they're the same, then the user
> hasn't touched the old default so copy the new default in.  If they're
> different, then prompt the user as in (2).  So we need to store
> checksums of default config files somewhere.  This is Debian's method.
> Again if this is the preferred method, then someone should develop a
> standard method to handle it.

This is similar to the current approach used by some packages (coreutils,
man, base-files).

> Is one of these approaches, or some other one, preferred for Cygwin?

The most common approach does the following:

1) On installation, create a manifest file in /etc/preremove with the
   names of the config files.
2) In the preremove, compare each config file from the manifest with the
   current default version of that file, and remove the config file if
   they are identical (using cmp).
3) In the postinstall, do what you proposed in step 1 above -- since we
   know that the config file will not be present anymore if it was
   unchanged.  This is also where the manifest is created.

The main problem is switching from the current state of affairs (i.e., a
config file that is never replaced) to the new (where the unchanged config
file is replaced).  The way some maintainers handled this situation was by
recommending (in the update announcement) to remove the config file before

> Or is it up to my discretion?

As a maintainer, it's always up to your discretion how you handle the
packages you maintain.  However, there's a benefit in adopting a uniform
model for config file handling, since setup can (at some point in the
future) be changed to recognize these config files and perform the update
      |\      _,,,---,,_ |
ZZZzz /,`.-'`'    -.  ;-;;,_		Igor Peshansky, Ph.D. (name changed!)
     |,4-  ) )-,_. ,\ (  `'-'		old name: Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
"But no -- you are no fool; you call yourself a fool, there's proof enough in
that!" -- Rostand, "Cyrano de Bergerac"

More information about the Cygwin-apps mailing list