Ok, I've run some tests and asked Julien Cristau about startx behavior. Basically, if we want a “fully loaded” Xfce session, with complete user experience, we need to be able to shutdown through hal, and to mount/umount devices easily. For that, we need access to hal, and so we need policykit permissions, given by consolekit (something like that).
To have that, there is two major cases: - login through a display manager - login from the console From a display manager, /etc/X11/Xsession.d/90consolekit will always be run, and position correctly the ck stuff. This is the simple case :) From the console: - either libpam-ck-connector is installed - either it's not If it's installed, consolekit stuff will be positionned at login, and should be propagated to any desktop run from there. And that's why 90consolekit should _not_ be run, and why the pam module sets a variable to be sure. If it's not installed, the console login won't have consolekit stuff, and if we want a complete desktop experience, we _need_ to use 90consolekit, and so run stuff in /etc/X11/Xsession.d (and still run startxfce4). The only way to do that (that I know) is to put: exec startxfce4 in .xsession, and run: startx (no .xinitrc, no startx /usr/bin/startxfce4 or anything else). So, if we document that in README.Debian, everything should work fine for most user, wether they use a DM (case 1) or not, and have libpam-ck-connector installed (2a) or not (2b). But we have a problem with 2a because in some cases which you exposed in I don't remember which bug, that the ck session on console wasn't propagated to the desktop session. Could you give (on that bug) a summary of how to reproduce this? Cheers, and thanks for working on this issue :) -- Yves-Alexis
signature.asc
Description: This is a digitally signed message part