Re: Hooking up gnome-session with dbus/kdbus/systemd

[Lennart Poettering <mztabzr 0pointer de>]

On Tue, 28.01.14 09:56, Sriram Ramkrishna (sri ramkrishna me) wrote:

> > c) gnome-session currently has some special .desktop file support that
> >    it uses to set up the session and run it (parsing stuff from
> >    /etc/xdg/autostart). For that it forks off all
> >    processes on its own, and will wait for SIGCHLD to bind the lifecycle
> >    of the session to the lifecycle of gnome-settings-daemon +
> >    gnome-shell. It also uses that to implement "phases". I'd like to see
> >    this minimally changed to watch for the
> >    existance of the respective bus names instead, and use normal bus
> >    activation to start everything. The phase logic can stay in
> >    gnome-session even if gnome-session doesn't fork anything of
> >    anymore but uses bus activation for every>
>
> So this seems like we are going to continue to use gnome-session in
> order to maintain support for non-systemd operating system.  My
> question is, why not at least move everything to systemd --user for
> systemd sessions instead of maintaining gnome-session?  That way we
> get the benefits of things like bootchart and have more direct control
> of how GNOME starts?

gnome-session does a number of things where we don't want to see systemd
get involved with. For example, in .desktop files there are some GNOME
specific settings which allow you to bind it to a specific dconf key,
and I am pretty sure systemd should not hook into that (not because
dconf was bad, but simply because we should try hard to avoid making
systemd a client of the daemons it manages). Also, note that we systemd
we actually are changing the scope of things a bit. While previously
gnome-session would be run inside the original user session and would
then fork everything off directly, also inside the user session, we want
a different layout in a systemd world: instead of having everything run
inside session scope, we want to move things to user scope. Which means
everything is forked off a singleton per-user systemd --user instance
that is shared by all active sessions. Now, to start a service we still
need one component though that continues to run in the session and just
tells the systemd --user instance to spawn gnome-settings-deamon,
gnome-shell and all the other services... We want this one component to
be gnome-session.

> I've heard some unsubstantiated claims that KDE is moving to this
> model and is replacing startkde with systemd --user session.  I'm not
> sure what they are planning to do with non-systemd OS, but apparently
> they seem to be calling them "legacy" systems.  Maybe not an
> appropriate label IMHO.  But it seems that there is room to at least
> consider moving wholesale to systemd --user instead of maintaining a
> frontend and then changing everything behind the scenes.

My expectation is that they'd follow the same scheme here: continue to
have some small tool that goes to the systemd --user instance and just
asks it to start whatever is needed.

But then again, I haven't talked to the KDE guys about this. I probably
should though. Maybe Ryan, we should do another fdo summit like last
year? What do you say? Maybe organized next to some other European
conference, like LinuxTag or so?

Lennart

-- 
Lennart Poettering, Red Hat