dbus-broker-launch does not respect XDG_DATA_DIRS

[mbiebl]

My first attempt at working around #38 was to create an empty file /usr/local/share/dbus-1/services/org.kde.dolphin.FileManager1.service

It seems though as if dbus-broker-launch completely ignores any paths set via XDG_DATA_DIRS and only looks at /usr/share/dbus-1/services.

[teg]

Thanks for the report!

[dvdhrm]

Yeah, I am aware of this. This is implemented by dbus-daemon as the standard_{session,system}_servicedirs configuration option. We should really follow XDG_DATA_DIRS here, rather than just hard-coding the single default path.

[dvdhrm]

@mbiebl, we now properly parse all the directories. See 28b926d.

I will close this. Lets track the duplicate-file handling in the other issue.

Thanks a lot!

[carewolf]

But where do you set XDG_DATA_DIRS so that it is picked up by the dbus launch? It apparently never reads .profile or related user setup files.

[dvdhrm]

With XDG_DATA_DIRS I was mainly referring to the xdg-specification, not the env-variable itself. Right now, we never read the XDG_DATA_DIRS environment variable, but rather just use the default search-path as defined by the spec. However, we will gladly implement support for the env-variable, if that is needed.

Can you elaborate what your use-case is? Why exactly do you need to adjust the broker's search path for service files?

Furthermore, please note that only the session bus honors XDG_DATA_DIRS. The system bus uses hard-coded search-paths (we follow dbus-daemon(1) behavior here).

Lastly, XDG_DATA_HOME is properly supported. That is, ~/.local/share is searched by default, unless you make XDG_DATA_HOME point to some other directory.

Also, dbus-broker is usually spawned through its systemd unit, just like dbus-daemon is. So any environment variables available to systemd --user are inherited by dbus-broker (I think...). Can you elaborate on your use-case? I'd be interested what setup you have, so we can see whether XDG_DATA_DIRS should be implemented.

[carewolf]

The use-case is to have an application/DE installed in a prefix. See also https://blog.martin-graesslin.com/blog/2014/06/dbus-activation-for-apps-in-prefix/

There is a work-around by using system setup, but it would be better if the launched dbus session daemon would read user variables.

[dvdhrm]

Fair enough.

[dvdhrm]

Completely forgot about this bug-report, I should have re-opened it...

Anyway, XDG_DATA_DIRS is now supported in the newest release. Thanks a lot for the comments from everyone involved!