Bug 135510 - [INVESTIGATE] Robust Configuration management across upgrades
[INVESTIGATE] Robust Configuration management across upgrades
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Warren Togami
Mike McLean
: 138970 (view as bug list)
Depends On:
Blocks: FC4Target
  Show dependency treegraph
Reported: 2004-10-13 03:19 EDT by Warren Togami
Modified: 2007-11-30 17:10 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-29 02:47:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Warren Togami 2004-10-13 03:19:25 EDT
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):
Comment 1 Ray Strode [halfline] 2004-10-13 03:52:41 EDT
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.
Comment 2 Warren Togami 2004-10-13 04:07:14 EDT
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?
Comment 3 Sam Varshavchik 2004-10-13 07:09:48 EDT
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.
Comment 4 Bill Nottingham 2004-10-13 16:17:48 EDT
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.)
Comment 5 Sam Varshavchik 2004-10-13 19:01:50 EDT
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.
Comment 6 Warren Togami 2004-10-20 00:46:22 EDT
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.
Comment 7 Bill Nottingham 2004-10-20 01:21:29 EDT
The correct way to fix this is to change the RPM algorithm.
Comment 8 Warren Togami 2004-10-21 06:43:21 EDT
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.
Comment 9 Warren Togami 2005-03-29 02:47:45 EST
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
Comment 10 Ray Strode [halfline] 2005-04-12 17:27:26 EDT
*** Bug 138970 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.