Re: GDM version used for GNOME 2.24?

[Brian Cameron <Brian Cameron Sun COM>]

Andre:

This question seems to have created a lot of FUD, and I wanted to try
and give a more clear perspective on the situation.  As the maintainer
of GDM for the past several years, I feel I have a good understanding
of the needs of GDM users, and what will cause issues.

First of all, I don't think that the loss of gdmgreeter or the GDM
themes is a real issue.  Some users will find it annoying that their
favorite theme can't be used, but if there is enough interest in
supporting such themes long-term, then we can imagine such users will
push for it to be rewritten to use the new infrastructure.  This
probably isn't a huge amount of work.  The old greeter just needs to
be updated to use a different IPC mechanism.  However, there are
a few design issues that probably would need to be considered.  Session
and language choosing has changed in the new GDM, so it might make
sense to revamp things like this when porting the old greeter.  Also
making it GObjectified is perhaps a bit of effort.  Users who really
love the old theming can probably just continue using GDM 2.20 if they
want.  Such users probably are geeky and would know how to replace or
rebuild a module.

Secondly, I do not think the loss of gdmsetup is that big of a deal.
Most configuration options in GDM can now be configured via
gconf-editor.  There are still a few daemon configuration options in
/etc/gdm/custom.conf, but not the ones users typically want to modify
(except for perhaps automatic/timed login).  I think that people can
probably live with using gconf-editor and their favorite ASCII file
editor for updating the configuration for now.  The old gdmsetup
program had a real security flaw in that it needed root permissions
to run.  It would be better if the GUI ran as the "gdm" user.  So
it needs a rewrite anyway.

That said, I think the two issues that are of real concern are the
fact that the new GDM does not support managing multiple displays
when each display has its own graphic card.  The second issue is
that you can't run the XDMCP chooser from the login GUI.

The need to manage multiple displays is commonly used in terminal server
environments.  Distros who want to support terminal server setups out of
the box simply can't consider the new GDM.  It is probably reasonable to
expect this regression could be fixed by GDM 2.26.  At any rate, until
it is fixed some distros, like Sun, will not be able to include the new
GDM.  I imagine some other distros that need to support terminal server
environments will likewise stick with GDM 2.20 until this regression is
addressed.  Since this is an important feature for many users, I can't
imagine this regression will be broken for long.

Users who want to be on the bleeding edge could try to support multiple
server environments using the GDM patch that makes gdmdynamic work with
the new GDM:

  http://bugzilla.gnome.org/show_bug.cgi?id=536355

Using GDM built with this patch, you could add multiple displays
via scripting rather than hardcoding the displays in the configuration
file.  Using this sort of technique, you could do some interesting
things, like if HAL detects a hotplugged display, you can manage or
unmanage the display on the fly by just calling gdmdynamic.

The fact that you can not run the XDMCP chooser from the login GUI
anymore is the other problem.  That said, XDMCP is crufty and insecure,
so it might be reasonable to take the stance that it is now a second
class citizen and regressions are okay in this area.  However, I believe
there are enough XDMCP users out there that I also can't imagine this
regression will be broken for long.

I am not aware of any other regressions that I think are particularly
serious.  Now that the documentation is mostly put together, and
there is some reasonable configuration migration support since the
new GDM still supports the /etc/gdm/custom.conf file for options
which make sense; I think GDM is in much better shape than it was
a few weeks ago.

While these are just my opinions, I think that it is reasonable for
the release team to bless the new GDM with the understanding that
some distros won't update until some of the more important regressions
are addressed.  The new GDM is appropriate for use on distros where
the intended audience isn't likely to want to run complicated setups
like terminal servers.  Most distros that ship the new GDM would likely
also make available RPM's/binaries/whatever for the old GDM, so that
users who have such needs can backport to the old GDM for these
regressed features.

Or, I could also understand if the release team felt that GDM needs
a bit more polish before its ready to go out the door.  I would think
another release cycle would get us that much closer to addressing the
more serious regressions.

It's really the release team's decision at this point.  I don't think
there is enough time to address these remaining regressions in this
release cycle.  The design considerations regarding how ConsoleKit
and GDM should interact regarding supporting multiple displays hasn't
been figured out in enough detail yet.

Brian


> the release-team normally asks on d-d-l for comments on new modules and
> dependencies.
> In this case I'd like to ask for valuable feedback on gdm trunk.
>
> Among the release-team there are different opinions whether to use trunk
> or 2.20.x for GNOME 2.24 and hence different opinions on regressions
> (and the definition of that term) and missing or rewritten
> functionality.
> As far as I know, Fedora and Foresight ship trunk, while Ubuntu and
> Mandriva tend to ship 2.20.x. Opensuse releases in December so no real
> use in asking them. No idea about Debian.
>
> Don't know if providing links to former discussion threads might
> influence opinions. Feel free to ignore these links and to share your
> own non-influenced experience instead:
> http://mail.gnome.org/archives/release-team/2008-August/msg00021.html
> http://mail.gnome.org/archives/gdm-list/2008-July/msg00028.html
> http://mail.gnome.org/archives/release-team/2008-August/msg00072.html
>
> We'd like to have a decision made by this weekend so there's two weeks
> left for translators. Comments highly welcome, so you can't blame
> release-team only in the end. ;-)
>
> andre