Requesting code change after freeze

[Brian Cameron <Brian Cameron Sun COM>]

Release team:

I would like to make a code change to GDM after the code freeze to avoid
user issues, confusion, and needless bug reports.

As you may know, the mechanisms for handling configuration has been
revamped in GDM 2.14 so that the configuration files are stored as
/usr/share/gdm/defaults.conf for distro defaults and
/etc/gdm/custom.conf for user customizations.

For backwards compatibility, the GDM daemon recognizes that if the user
has the old /etc/gdm/gdm.conf file installed on their system that this
is used as the custom configuration.  This ensures that the daemon
continues to use the old configuration so users should not see any
configuration choices get lost on upgrade.  That all works okay.

The problem is with "gdmsetup" which only edits the custom.conf file.
So that when the user runs gdmsetup, the changes do not take effect
unless the user moves aside their gdm.conf file (or moves it over
their custom.conf file).  This is, I think, more annoying and
confusing than anything.  No data is lost, GDM just doesn't
recognize any changes until the user deals with manually migrating.

There are two ways to fix this problem, and I'll explain them
because it would be useful to get some feedback from the release
team about the right approach.

1) The solution I would recommend is to add a new "gdmflexiserver
   --command" called "GET_CUSTOM_CONFIG_FILE" so that gdmsetup can find
   out the name of the custom config file that is being used by the
   daemon.  Then gdmsetup will modify the gdm.conf file and the
   custom.conf file will be ignored.  The user can choose to migrate
   (or not) at their leisure.

   Since this gdmflexiserver command option is only being used by
   gdmsetup at the moment, I think we can avoid adding info about
   this new command in the GDM user documentation and avoid string
   freeze issues.  This can be documented in the 2.15 docs.  Really,
   applications not in the GDM module should not try to parse the
   config files directly and should instead use the "GET_CONFIG"
   command to get config data.  So this command is really intended to
   be a private interface of GDM and perhaps shouldn't be documented
   at all, anyway.

   This is an easy change to the code and would be easy to ensure that
   it would work properly.  This is the safest approach to make things
   work reasonably, I think.

2) Perhaps a "nicer" solution would be for GDM to automagically migrate
   the users gdm.conf settings to the custom.conf file and not use the
   gdm.conf file at all.  The problem with this approach is that some of
   the gdm.conf configuration settings (mainly the [server] and
   [server-foo] sections) are a bit tricky to migrate.  This would make
   the migration code a bit tricky to implement and perhaps not an
   appropriate change late in the release cycle.  This sort of migration
   could be added in the next release if people think that is a good
   idea.

   If the release team thinks this is the better approach, I think I
   can make this work.  I just worry that any bugs in the code would
   cause the users more issues than doing nothing, and I would be more
   comfortable adding this sort of logic in 2.15/2.16 than now.

Thanks,

Brian