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): gdm-2.6.0.5-4
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. http://www.courier-mta.org/sysconftool/ I had in something something like this used by courier and cone. https://bugzilla.fedora.us/show_bug.cgi?id=1457#c13 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 carried forward. Generally, when upgrading to a point minor release, speaking in a very general sense, what - 90%? - of all configuration settings will remain the same.
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 packages too.
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 metadata downstream. 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 Project. WONTFIX
*** Bug 138970 has been marked as a duplicate of this bug. ***