Problems from old config files

[Patrick O'Callaghan]

On Fri, 2009-11-13 at 03:42 +0100, Kevin Kofler wrote:
> Patrick O'Callaghan wrote:
> > We clearly need a way of dealing with this. I guess transparent updating
> > is a lot to ask, but at least detecting obsolete config files and
> > warning the user should be a high priority for future KDE releases.
> > Would it be too hard for each config file to include a comment line at
> > the beginning with the version of whatever KDE component created it, and
> > new versions of that component to check the line for compatibility?
> 
> Well, in principle that's what kconf_update is for, but due to various 
> limitations:
> 1. Several KDE apps will keep settings in memory and write them out if 
> closed, not reloading changes made to the config file in the meantime. This 
> breaks if kconf_update runs while the application is running. (This is 
> particularly annoying with Plasma config files, kconf_update is basically 
> useless for those.)
> 2. Not all known configuration file changes have corresponding kconf_update 
> scripts.
> 3. Not all issues caused by old configuration files are known. Sometimes a 
> setting which used to be valid isn't anymore for whatever reason and this is 
> often very much non-obvious.
> this doesn't always help.
> 
> For 1., either kconf_update or KConfig or both need fixing (I'd fix this in 
> KConfig by writing any changes to disk automatically and by setting a 
> KDirWatch on the config file to reload on-disk changes automatically, but at 
> least Aaron Seigo clearly expressed his dislike for that solution and 
> suggests having kconf_update talk to running applications over D-Bus 
> instead),

Maybe it doesn't need to get that complicated. I see this part of the
problem as a race condition between the update process and the running
component. If the running component wants to write to the config file it
should simply notice that it has changed since the component last read
it and either abort the write or ask the user what to do (I'd be more in
favour of aborting and telling the user why).

>  for 2., upstream developers need to do a better job of adding 
> kconf_update scripts if they change the format of their configuration files 
> (but ideally they should just not change it!), 3. is the biggest problem (as 
> sometimes even the upstream developer of the application isn't aware of the 
> issue nor its cause).

I understand that, but I ask again: "why does Gnome not seem to have
this problem?"

poc