[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#723948: libatk-bridge-2.0-0-udeb: uninstallable; depends on missing libatspi2.0-0 (>= 2.9.4)

On 04/10/13 00:36, Samuel Thibault wrote:
> Simon McVittie, le Thu 03 Oct 2013 12:37:07 +0100, a écrit :
>> On 03/10/13 12:09, Samuel Thibault wrote:
>>> It essentially needs dbus-launch, to start dbus-daemon.
>> Is this the session bus, or a parallel bus, or both?
> I don't really know what that means.  What I can see in the source code
> (at-spi2-core/bus/at-spi-bus-launcher.c) is this:
>   name_owner_id = g_bus_own_name (G_BUS_TYPE_SESSION,
>                                   "org.a11y.Bus",

That's a session bus, so you need to get one started, somehow.

The automagic mechanism which D-Bus has always had is that clients'
default session bus address (if they don't see any relevant environment
variables) is "autolaunch:", which means "fork-and-exec dbus-launch,
which will look in X11 window properties to try to find a session bus,
and if there isn't one, start one itself and advertise it in X11 window
properties". The *other* automagic mechanism is to run dbus-launch from
a file in /etc/X11/Xsession.d, so that there's already one running.

I consider this to be rather unpleasant, particularly the autolaunch:
bit (dbus-launch is poorly-documented and confusingly-implemented): it's
primarily there to support the "run a single GNOME/KDE app under fvwm"
use-case. I'd prefer it if graphical environments that want D-Bus could
run their own dbus-daemon and put $DBUS_SESSION_BUS_ADDRESS in graphical
clients' environment. g-i is basically a very small graphical
environment, so I'd prefer it if g-i could take responsibility for doing

dbus-run-session(1) is a new tool which I added to make that easier:
it's a "command prefix"-style tool, like chroot or sudo (but retaining a
supervising parent process rather than ending with an exec(), so more
like schroot, really). It starts a dbus-daemon as a child, finds out the
address, and starts the process given in its arguments (the session) as
a second child, with the D-Bus address in its environment. It watches
its children until the session terminates, then kills the dbus-daemon
and exits itself.

For now, my plan is to put together a dbus-udeb (with dbus-daemon,
dbus-uuidgen and probably dbus-run-session), a libdbus-1-3-udeb, and
possibly a dbus-x11-udeb containing dbus-launch. I'd appreciate it if
dbus-x11-udeb could go away before Jessie is released, though.


Reply to: