This is the mail archive of the cygwin-apps mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: best practice for upgrading config files?


On Wed, 10 May 2006, Thomas Wolff wrote:

> Igor Peshansky wrote:
>
> > ... 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
>
> This is certainly true.
> (On the other hand, having experienced this nuisance of certain packages
> a number of times, it is good advice anyway not to rely on changing
> system configurations whenever possible, but rather add overriding local
> configurations.)

As long as you only change existing option values, the patches should
apply (possibly with some amount of fuzz).  But if you add new
configuration option settings, there is a possibility of changing the
state of the config file to something invalid.  If you're really that
concerned with the users keeping their changes *and* getting new updates,
split the configuration files into user-modifiable (i.e., those that will
only have the user-overridden settings) and standard (which should not be
modified by the users), and include the user-modifiable version into the
standard one (if your application supports it).

> But - again on the other hand - if a new release brings in additional
> parameters, I would of course want them to show up in the configuration
> so they become effective (and configurable :).
>
> > 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.
>
> Considering what I said above, I think an automatic merge would be the
> best, not changing modified parameters, and adding any new parameters.
> Apart from some moderate handling effort, the only remaining problem
> would be whether to change default values of previously unchanged
> parameters - which might have been deliberately unchanged by the user!

Dealing with configuration files is usually quite a large can of worms.
The users are expected to read release announcements (though I admit,
Cygwin setup doesn't make it very easy to find them[*]).

> > > (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.
> > > ...
>
> > 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).
> > ...
>
> Approaches which either can only replace or not, depending on
> comparison of the complete file, or delegate all merging problems to
> the user, are unsuitable for my taste.

Unless the part that you're comparing *can* be replaced as a whole (i.e.,
all user changes are confined to another file that is included into the
main config).

[*] Would there be interest in propagating URLs of announcement messages
in setup.ini, so that Cygwin setup can let the users view the
announcements from the chooser screen?  An alternative would be keeping
this information separately on the sourceware server, writing a CGI script
that would retrieve the announcement(s) based on the range of versions,
and have setup reference the URL of that CGI script instead.  The database
of announcements could be updated when announcement messages are forwarded
to cygwin-announce, but I don't know enough about that mechanism to offer
any concrete suggestions at the moment.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_	    pechtcha@cs.nyu.edu | igor@watson.ibm.com
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"


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]