Red Hat Bugzilla – Bug 135510
[INVESTIGATE] Robust Configuration management across upgrades
Last modified: 2007-11-30 17:10:51 EST
Description of problem:
gdm when upgraded always resets /etc/X11/gdm/gdm.conf back to
defaults. RH's gdm package explicitly does not use %config(noreplace)
because in the past the gdm.conf file format or required keys changed.
This is a huge hassle for system administrators who need non-default
settings in gdm.conf. For the long term we should work on some
mechanism for clean settings migration during upgrades.
Version-Release number of selected component (if applicable):
For reference, noreplace was removed because of bug 71309.
What kind of mechanism do you have in mind? The only sensible
mechanism I can think of would be to make sure newer GDM releases
support older config files.
It's been 2 years since bug 71309. We probably need to see if this is
still a real problem. It seems quite conceivable to me that the
config format has stabilized and/or GDMs backward compatibility has
improved since then.
If we add %config(noreplace) back, it will keep the old gdm.conf
during an upgrade from ANY old version of gdm.conf will be retained.
We totally have not tested old gdm.conf with our gdm, so the result
may be totally unexpected and difficutl to support.
I had in something something like this used by courier and cone.
Read this for a short description of what it does.
Perhaps Sam Varshavchik has ideas or could provide clarification?
The proper place to add sysconftool support would be in the upstream
package, otherwise for each release you'll have to go through the
upstream configuration file, figure out what's changed, and manually
augment the configuration file with sysconftool's metadata.
Upstream will also have a better grasp on what's changed in the config
file; what's new; what's been obsoleted; and what has changed that's
not backwards compatible, and must be reset to the default.
It's a matter of which you want, really:
- do you want each upgrade to overwrite local config and start
correctly with the wrong config?
- do you want an upgrade to a non-compatible version to immediately
stop working, so you know that it needs fixed?
The second seems simpler, and is consistent with what we do for
many other packages (sendmail, vsftpd, etc.)
A proper application of sysconftool; and a well-designed configuration
proper, gives you the best of both worlds. You have control over each
individual configuration setting; the metadata will specify whether
each individual setting is to be left alone, or reset to a default.
You will also indicate which settings have been removed, and which
settings are new and must be added to the configuration file.
sysconftool is logically equivalent to RPM's %config directive, except
that it's granularity is on a per-configuration setting basis.
Or, another way to put it, sysconftool places an arbitrary version tag
on each individual setting. With sysconftool, each upgrade installs a
new configuration file, except that settings common to the old and the
new configuration file, and that carry the same version tag, are
Generally, when upgrading to a point minor release, speaking in a very
general sense, what - 90%? - of all configuration settings will remain
We should investigate sysconftool (and other approaches) as an option
to solve this and similar problems for hopefully FC4. Reassigning to
distribution as this most likely would be useful for many other
The correct way to fix this is to change the RPM algorithm.
I am in disagreement that changing the RPM algorithm is robust and
fine grained enough to do what is needed. IMHO, what you suggest with
diff and merging is far too limited and error prone, but I am
interested to see study these existing implementations. I wish to
investigate better options *like* sysconftool. And of course whatever
is implemented would need to be accepted upstream, because it is too
much of a maintenance burden to manually generate configuration
Setting this as a FC4Target to keep it on the radar.
While gdm still sucks for wiping out its config file on upgrade, I have no time
to fix this. If someone else cares they need to work with the upstream GNOME
*** Bug 138970 has been marked as a duplicate of this bug. ***