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
that.
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.
S
Reply to: