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

[Sascha Silbe]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101109/c4f3883a/attachment.pgp>