[Pkg-utopia-maintainers] Bug#520720: Bug#520720: gnome-power-manager: Stopped working after consolekit upgrade)

[Yves-Alexis Perez]

On mer, 2009-04-29 at 08:55 +0200, Michael Biebl wrote:

> > 
> > The I just fail to see why libpam-ck-connector from oustide of X creates
> > the XDG_SESSION_COOKIE. What is it used for?
> 
> Trying to answer both of your questions:
> It's indeed questionable, what a CK session on the console is good for.

In fact I meant, why is the XDG_SESSION_COOKIE used for. Not why a CK
session on the console is good for. I have no problem with the latter
(it could be very useful to have all the siny desktop stuff from the
console too, for example). I thought XDG_SESSION_COOKIE was just used to
determine that a X11/CK session was running.

> So a first step to "avoid" this kind of problem, is indeed, to make the
> libpam_ck_connector Recommends a Suggests. It's obviously not a real fix.

Yeah, I'm not fan of that, because there might be perfectly legitimate
reasons to have the pam module, and I don't think it should break
working setup.
> 
> The only other reason I can think of, why libpam_ck_connector might be useful,
> is if you setup a custom pam configuration without nox11 for a login manager
> that does neither support Xsession.d nor talk to CK directly.

Hmhm, that might be a bit pervert, no?
> 
> 
> >> 2.) login on the console (covered by libpam_ck_connector)
> > 
> > Yes (but afaict we don't need XDG_SESSION_COOKIE)
> 
> See below
> 
> > Basically, I think I'd be fine with libpam-ck-connector not using
> > XDG_SESSION_COOKIE when it's in console mode (nox11) because it doesn't
> > really make sense.
> 
> I think we can't get rid of the XDG_SESSION_COOKIE variable, as this is
> necessary to correctly track/assign a session to a user. (I'll verify that though)

I wasn't aware of that :) I just thought it was a was to know if there
was an X11/XDG session currently running. The name may not be wisely
chosen then :)
> 
> That's why I proposed the idea of an additional/separate env var, that will only
> be set for console logins, so we can easily differentiate X11 from console
> logins in Xsession.d/90consolekit.

That could be a good idea. In fact, what we want (correct me if I'm
wrong) is a way, in 90consolekit, to know if we should override the
currently running CK session or not. If there's no session, fine, run
inconditionnaly, but if there's already a CK session there might be
multiple cases (CK-aware DM, CK-pam + DM, CK-pam + console), in some
cases the CK-session should be kept, in some other it should be
overriden.

Am I correct?

Cheers,
-- 
Yves-Alexis