dbus-daemon-launch-helper(?) seems to ignore XDG_DATA_DIRS
I might have missed something, but here my lines of thoughts and actions:
The D-Bus specs say:
On Unix systems, the session bus should search for .service files in $XDG_DATA_DIRS/dbus-1/services.
They also define for the org.freedesktop.DBus
interface the method org.freedesktop.DBus.UpdateActivationEnvironment
:
Normally, session bus activated services inherit the environment of the bus daemon. This method adds to or modifies that environment when activating services.
The method UpdateActivationEnvironment
is e.g. used by the tool dbus-update-activation-environment if I saw correctly. When using that tool, it confirms me that it has set for the D-Bus session instance the respective value of XDG_DATA_DIRS, which contains the respective .../share
dir which otherwise also works,
Yet when trying to launch the service/application via the D-Bus service file, the error is "The name org.foo.bar was not provided by any .service files".
If instead the D-Bus service file is placed into the default user's .local/share/
prefix, the service is launched as expected.
I am not exactly sure if dbus-daemon-launch-helper is involved here (openSUSE Tumbleweed), but it is installed, so possibly used (instead of any newer systemd-based launcher I saw mentioned?). I looked into the code of that tool, and by first glimpse it seems to reset any environment variables and only reads existing config files, and thus initializes the config parser also only with the default values for the 'XDG_*' variables and thus ends only checking & listing service files seen in the user's default .local/share/
for me (not changed those config files from distro defaults). But I might have been biased by expectations while trying to grasp code behaviour in my head :)
So would there be a bug here (and then in that place) or is this expected hebaviour?
If my expectations from reading the docs are flawed and the method UpdateActivationEnvironment
is not meant to support this purpose, what other kind of activation should it support?
My general goal is to make more applications DBusActivatable, by tagging that in the desktop files. Which also needs a separate D-Bus service file AFAIK. For the development setup I would like to install only to my user's local paths, to not break the system for other users, and ideally not have to maintain further config files. That works fine otherwise, including integration with the shell, thanks to XDG_*
variables. But for starting via D-Bus service files, I currently hit a wall and need to find a proper widely acceptable door now :)