[Sugar-devel] Heads up: dbus upstream planning to break sugar-jhbuild and sugar-emulator

[Bert Freudenberg]

Thanks for the warning. 

But it doesn't seem so bad to me, and it will take some time until distros adopt this. At least we can replace the magic to guess the user's session bus if you log in on a VT ...

And, since the user bus is in addition to the system and session bus, jhbuild can still create a new session bus. Sugar could be given an option whether to use the user or session bus.

It's a bit more complicated for activities, which need to know if they should open their service on the session bus or on the user bus. But I'm sure this can be figured out in time too.

Overall a user bus makes a lot of sense to me :)

- Bert -

On 09.11.2010, at 23:47, Sascha Silbe wrote:

> Hi!
> 
> This is just an early warning that the dbus folks are currently
> planning on introducing and making the default a "user" bus instead
> of the current "session" bus. The following mail has just arrived on
> the dbus mailing list; I haven't replied to it yet (if anyone would
> like to join the discussion, please don't wait for me to do it first).
> 
> The first thing that comes to my mind that this proposal will break is
> sugar-jhbuild. It relies on being able to set various environment
> variables so that (a new instance of) dbus-daemon starts various Sugar
> services (most importantly the data store) from within the sugar-jhbuild
> prefix.
> 
> The second thing that will break is sugar-emulator. It starts a new
> instance of dbus-daemon in order to isolate the new session from the
> current one. The following sentence from the mail nicely illustrates
> that they're aware this will cause trouble:
> 
>> All of this means that there is only one graphical login per user.
> 
> 
> --- Begin forwarded message from Ryan Lortie ---
> From: Ryan Lortie <desrt at desrt.ca>
> To: dbus <dbus at lists.freedesktop.org>
> Date: Tue, 09 Nov 2010 23:06:42 +0100
> Subject: User bus conclusion
> 
> Hi,
> 
> At the Boston summit I had a chance to sit down with Lennart and discuss
> the mess we've been going over for the past while.  We came to a strong
> conclusion on all points.
> 
> We also discussed the conclusion we reached with some others in
> attendence and got some rather positive feedback.  I'm going to attempt
> to document the conclusion here, but I may get some things wrong or
> leave some things out.
> 
> The most significant take away is that we will add a "user" bus to DBus.
> This bus will be defined as scoped to one user on one machine.  Multiple
> logins of the user to the same machine will share the same bus.  systemd
> will be managing this.
> 
> The bus will listen at a well-known path relative to the user's runtime
> directory.  See:
> 
> http://lists.freedesktop.org/archives/xdg-list/2010-November/011681.html
> 
> The path will be "$XDG_RUNTIME_DIR/dbus/user_bus_socket".
> 
> In systemd style, the user bus won't be started until someone actually
> tries to the connect to the socket.  If you ssh in, for example,
> probably DBus won't be started, but if you try to use it then it will.
> 
> DBus client libraries should add knowledge of this new bus type.
> 
> 
> That's it in terms of changes to DBus.  What follows is a list of
> changes that we recommend will occur to the system as a result.  Of
> course, that's up to vendors and distributors.
> 
> - we recommend the session bus will no longer be started
> 
> - we recommend that the DBUS_SESSION_BUS_ADDRESS environment variable
>   be set to the socket of the user bus (to support old DBus client
>   libraries and/or applications)
> 
> - maybe eventually DBus client libraries can issue deprecation warnings
>   to stderr about session bus use by applications
> 
> - the DISPLAY environment variable will be unset
> 
>   It needs to be this way when you consider that X may not be running
>   at all when the user dbus first starts (in response to an ssh
>   session, for example).
> 
> - libX11 (and xcb?) will be modified so that an unset DISPLAY
>   environment variable means that the client opens the socket
>   "$XDG_RUNTIME_DIR/X11/socket" or such.
> 
>   This has the nice effect that we can use systemd to autostart a
>   rootless X server on-demand in our post-wayland existence.
> 
> - on login (for now) this will be a symlink to the one in /tmp
> 
> - we are against people doing tricks like "org.domain.MyApp1",
>   "org.domain.MyApp2", etc. to support app uniqueness on multiple
>   displays.
> 
> All of this means that there is only one graphical login per user.
> 
> I think Lennart is planning to do most of the work and I'm going to be
> helping with some small details; I've already made a couple of
> glib/GDBus patches, for example.
> 
> Cheers
> 
> --- End forwarded message ---
> 
> Sascha
> 
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel