Re: Requiring systemd for the gnome-settings-daemon power plugin

[Colin Walters <walters verbum org>]

On Tue, 2012-10-23 at 07:26 +0200, Bastien Nocera wrote:

> I don't see how this helps. The code just lives somewhere that's still
> within view (gnome-desktop isn't some magic module where things get
> hidden), 

But I'm also volunteering to help keep it compiling and at least the
systemd case tested.  You're *really* rejecting this based on the
premise that the CK code would exist somewhere in GNOME and it's too
much of a burden on you to ever even look at it?

At least Florian's reply earlier in the thread implied that he thought
centralizing the logind/CK burden would be a good idea, and I'd take
that to mean he would spend a bit of time helping out.

I just ran "git log gnome-settings-daemon/gnome-settings-session.c" in
the gnome-3-6 branch.  You have *never modified this code*.  It's
Richard, Rodrigo, Federico, and Matthias.  So I'm dubious about a claim
that this code is so dire that you can't even be bothered to have a
dependency containing it.

> gnome-settings-daemon's power plugin still requires logind to
> work, 

Now in contrast to the "session is active" code, this is a complex
codebase; 5000 lines is nothing to sneeze at.  Also, this bit is special
to g-s-d, unlike the "session is active" bit which a number of other
modules (gnome-shell e.g.) also need to query.

So it seems to me well within your rights as maintainer to say "only
systemd is supported here".

> and gnome-shell with upower/ConsoleKit will likely behave brokenly
> (given that there's no gnome-settings-daemon counter-part).

But the point is that we're not *regressing* anything for the CK case.
Sure, GNOME in the CK case will have bugs.  That's fine by me.  GNOME
has plenty of bugs, some of them even very embarrassing.

> What's the sudden attachment to ConsoleKit? You could just as easily 1)
> port to g-s-d logind code to use D-Bus, and write a shim on top of
> ConsoleKit that would export a similar API.

I took the previously working code.  It's not clear to me what benefit
the changes you're talking about would provide other than turning
compile-time detection into runtime detection, which is kind of useful
but not of critical importance.

So what's the path forward in your eyes?  Are you still suggesting that
GNOME immediately delete all CK code?

To be clear, my proposed plan is:

* Spend a little bit (not necessarily a lot) of effort to avoid
  regressing CK.
* It's OK if new features or bugfixes rely on logind.
* If particular complex functionality like the g-s-d power plugin
  gets too hard to map to both CK/logind, announce that in
  advance, give a warning that code will be deleted, if no one steps
  up to help, delete it.