search

bus1 / dbus-broker

Linux D-Bus Message Broker
https://github.com/bus1/dbus-broker/wiki
Apache License 2.0
675 stars 78 forks source link

dbus-broker should pick up environment variables #219

Closed damianatorrpm closed 4 years ago

damianatorrpm commented 4 years ago

dbus-broker should understand runtime changes to XDG_DATA_DIRS and start services accordingly when XDG_DATA_DIRS is set somewhere.

Somewhat related: https://github.com/flatpak/flatpak/issues/3342

dvdhrm commented 4 years ago

I do not understand. What do you mean with "runtime changes to XDG_DATA_DIRS"? Can you explain what exactly is not working?

damianatorrpm commented 4 years ago

@dvdhrm flatpak/flatpak#3342 explains it as well. dbus-broker should be able to start service files even if the XDG_DATA_DIRS environment variable is changed during session runtime (or set on a terminal). XDG_DATA_DIRS=$XDG_DATA_DIRS:$SHINY_NEW_DIR /path/to/dbus_activatable_app_that_needs_shiny_new_dir_where_service_file_is_located

e.g flatpak-installations that are added during session.

dvdhrm commented 4 years ago

Lets keep the discussion on the flatpak bug. I subscribed to the github-issue and will help figuring this out. I do not see any wrongdoing of dbus-broker so far, though.

damianatorrpm commented 4 years ago

What I see as the incorrect behavior of the dbus-broker is that XDG_DATA_DIRS=$XDG_DATA_DIRS:$SHINY_NEW_DIR /path/to/dbus_activatable_app_that_needs_shiny_new_dir_where_service_file_is_located will fail to start the dbus_activable_app as it does not pick up $SHINE_NEW_DIR as a directory to look inside for service files

dvdhrm commented 4 years ago

Yeah, that's what I meant. Just because you adjust XDG_DATA_DIRS on your terminal does not mean every application's copy of this variable is adjusted as well. So if you set XDG_DATA_DIRS before starting dbus-broker (and make sure to set it in its environment), then it should correctly read them. Note that ./dbus-1/services/ is appended to every directory listed in there.

damianatorrpm commented 4 years ago

Yeah, that's what I meant. Just because you adjust XDG_DATA_DIRS on your terminal does not mean every application's copy of this variable is adjusted as well. So if you set XDG_DATA_DIRS before starting dbus-broker (and make sure to set it in its environment), then it should correctly read them. Note that ./dbus-1/services/ is appended to every directory listed in there.

And flatpak has features like flatpak-installalations (see man flatpak) that create a new XDG_DATA_DIR. This is not read until reboot or dbus-broker restart which kicks you out of a wayland session. How do these two parts (dbus-broker and flatpak-installations) work together without reboot?

Probably an environment variable like DBUS_BROKER_DO_READ_NEW_DATA_DIR that makes dbus broker read the new flatpak installation and look also inside it is required.

Just because some old dbus implementation did not do something that is required by modern day vision (flatpak), does not mean it should not be done. There is also systemd which does a lot things better because it is designed according to the whole OS vision.

How to reproduce: 1) Make a flatpak installation 2) Install software that is a dbus activable service. 3) running fails as DBUS_BROKER does not read from that installation until reboot.

What needs fixing: A solution for above without reboot.

dvdhrm commented 4 years ago

I don't see what I can do for you here, sorry. The dbus-broker implementation follows exactly what dbus-daemon does.

Furthermore, I don't know why flatpak expects to be able to add directories to XDG_DATA_DIRS at runtime. Please report this against flatpak. They ought to comment on how this is supposed to work, because from the information I am given I don't see how this model was designed, nor how this is meant to work.

dvdhrm commented 4 years ago

I will close this issue here. The linked flatpak issue is, in my opinion, the correct place to discuss how flatpak can improve its configuration handling.

If someone proposes changes to dbus-broker, please feel free to open a new issue, or reopen this one. However, please keep in mind that dbus-broker-launch is a compatibility tool to dbus-daemon, so any possible deviations either need to be justified or implemented in dbus-daemon as well. This is the policy for the compatibility launcher.