Hide Forgot
Should always use gdm instead of kdm, unless only kdm is installed.
I don't think this is the correct way to go. This should be configurable by the sysadmin with an entry in /etc/sysconfig.
It's fine if it's configurable, but gdm should always be the default.
Fix you dm launcher to run gdm by default unless an alternate is defined in whatever you look at in /etc/sysconfig.
And back to initscripts where it was in the first place. ;-) gdm doesn't launch itself.
why don't people like the anaconda patch I produced? It will have the desired result, and works fine with the infrastructure already in place in prefdm for DISPLAYMANAGER.
I think the comment was just that the policy should just stay in prefdm. Patch attached.
Created attachment 70404 [details] use GDM by default, unless specified by DISPLAYMANAGER (ignore $DESKTOP)
will be in 6.89-1
See #72468 -- this currently breaks badly when upgrading systems which: 1. are running 7.3 or less 2. have both KDE and GNOME installed 3. have configured DESKTOP="KDE" in /etc/sysconfig/desktop On upgrades, /etc/sysconfig/desktop needs to be parsed and the DESKTOP line duplicated as DISPLAYMANAGER
Sorry, wrong number -- the bug I meant was Bug 72486
I'm not sure I'd call it 'breaking badly' - you get gdm and have to change DISPLAYMANAGER. It's mildly annoying, but nothing is broken.
*shrug* If I've bothered to configure a 7.3 system to use specific software, and the upgrade silently changes that w/ no documentation, that's "breaking badly" IMO. Imagine if null silently switched all 7.3 machines where the admin had used alternatives to select postfix back to sendmail, w/ no mention anywhere in any documentation of this behavior. That's exactly what you're doing here, only with the display manager instead of the MTA....
In this case (of the login display manager), we respectfully disagree.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72825 I humbly request that the minor modifications to /etc/sysconfig/desktop be made in order to reduce possible future confusion on this issue.
I definitely second Warren's request. While I disagree with Preston about this not being a bug (to me, as a customer, any configuration which I deliberately make and then RH upgrades remove is a bug), at least if it's documented people will know how to fix the damage done by the upgrade.
Closing this out, as things appear to be working correctly now.