Bug 32994 – kdm (3.2.0_beta1) and sessions: new behaviour

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Gregorio Guidi (RETIRED) 2003-11-08 03:23:38 UTC]

How things worked until now:
when kdm starts, the script /etc/X11/xdm/Xsetup_0 is executed
(a reference to this script is in the kdm config file:
/usr/kde/3.1/share/config/kdm/kdmrc).
Xsetup_0 reads the entries in /etc/X11/Sessions and modifies all kdmrc he can find so that they contain the line SessionTypes=... with all the available sessions (kde-3.1.4, fluxbox,...). kdm shows these entries in the session menu. When one of them is selected, kdm executes the script /etc/X11/xdm/Xsession with the session as argument (the script is referenced in kdmrc).
the argument is used by Xsession to set XSESSION and this variable is used to choose the right entry in /etc/X11/Sessions.

How kdm works in kde-3.2.0_beta2:
The kdm config file does not contain SessionTypes=..., it contains only the parameter "SessionDirs", which stores a list of directories. Those directories contain ".desktop" files; kdm reads them, determines if the session they refer to exists, and builds the drop-down menu in the frontend consequently. When an entry in the menu is selected, kdm calls Xsession with an argument that is the value of "Exec=" as stored in the .desktop file.

Result: now kdm is totally broken

Possible solution:
provide a new kdmrc, where SessionDirs points to a custom directory (f.ex
/usr/kde/3.2/share/config/kdm/sessions), where Xsession is the one that comes with kdm and not the gentoo one (/etc/X11/xdm/Xsession), and where Xsetup is a custom script.
The Xsetup script should read the entries in /etc/X11/Sessions and create suitable ".desktop" files to fill the SessionDirs directory.

Alternative solutions:
- As before, keeping the gentoo Xsession (this breaks the entries "Default",    "Custom", "failsafe" that kdm puts in the menu).
- let kdm ignore /etc/X11/Sessions and patch it to allow many instances of kde?
- Find a long-term solution for this mess?

I can provide an implementation of the first solution, in the form of:
the custom kdmrc (install into /usr/kde/3.2/share/config/kdm/)
the custom Xsetup (install into /usr/kde/3.2/share/config/kdm/)
little modifications to kdebase-3.2.0_beta1.ebuild

Notes: this does not solve #15615.
	Xsetup_0 is really ugly, I hope one day it will go away.

[Comment 1 Gregorio Guidi (RETIRED) 2003-11-08 03:25:33 UTC]

Created attachment 20416 [details]
kdmrc

goes in /usr/portage/kde-base/kdebase/3.2.0_beta1/

[Comment 2 Gregorio Guidi (RETIRED) 2003-11-08 03:25:56 UTC]

Created attachment 20417 [details]
Xsetup

goes in /usr/portage/kde-base/kdebase/3.2.0_beta1/

[Comment 3 Gregorio Guidi (RETIRED) 2003-11-08 03:27:43 UTC]

Created attachment 20418 [details, diff]
kdebase-3.2.0_beta1.ebuild.diff

modifications to the ebuild

[Comment 4 Caleb Tennis (RETIRED) 2003-11-10 06:35:27 UTC]

I think the first solution is probably the best in this case.  I'll look
into it and try to get it in as soon as I can.

[Comment 5 Gregorio Guidi (RETIRED) 2003-11-11 05:50:07 UTC]

I saw the commit, thanks a lot!
two notes:
the line with the substitution "s:_VERSION_:${VERSION}:g": I removed it
because it is no longer necessary.

If you want to custimize the kdm background as in preceding versions,
readd the line "cp ${FILESDIR}/${PVR}/backgroundrc ."

My diff removed it, but it can stay as well, it's just a matter of opinions...
Bye.

[Comment 6 Caleb Tennis (RETIRED) 2003-11-12 09:19:01 UTC]

I'm going to mark this as fixed (changed the last few things per your suggestion).  My guess is this will still require some more modifications later, but I think this is a good fix for now.

Thanks a lot!

[Comment 7 Joshua 2004-04-11 11:38:49 UTC]

This may help someone if you cannot log into kde after kdm login in kde 3.2.1. I had to run genkmdconf (in kde bin dir) to have it generate the necessary files. I'm not filing a bug in this as I hope it will be fixed as the new kdm takes shape.

[Comment 8 Gregorio Guidi (RETIRED) 2004-04-11 14:28:50 UTC]

In fact this is a tricky issue. As things stands now, to have kdm
working properly, you must have:
- a kdmrc which contains SessionDirs=/usr/kde/3.2/share/config/kdm/sessions
- kdmrc pointing to the Xsetup script provided by the ebuild
- kdmrc pointing to the right Xsession script
- the right Xsetup script

if something goes wrong (for instance if a user does not etc-update correctly),
breakages will occur (this system is not very resilient to errors).

If someone tries to solve a problem with genkdmconf, two things can happen:
- if genkdmconf is run without options, the files in /usr/kde/3.2/share/config/kdm
will be generated using what is found on the system (mainly copied from /etc/X11/xdm).
So every user could end up with a different setup (working or not)

- if genkdmconf is run with --no-old (or something like that), it will install
the default files. This will probably give a working kdm, but...

In either case, you will end up with a "buggy" setup: the customizations made
by the kdebase ebuild are not considered (for instance the directory 
/etc/X11/Sessions, which is gentoo specific, is ignored).

I hope I clarified the problem a bit, and I will gladly accept possible solutions ;)