Hi, (plasma-devel as CC: for heads-up, please reply only to kde-devel to keep discussion in one place)
at least with systemd controlled start (but possibly also before) of the session D-Bus (based on what I understood so far, please correct me) for a user is not possible just by editing their user's config files to control where the session D-Bus instance is looking at, e.g. to find user-deployed D- Bus service files. Anything is configured by things only an admin can modify. Which brings some challenges for installing D-Bus service files when installing user-built things into a user-selected prefix, like in case of usual KDE developer setups (e.g. ~/kde/usr as used in documentation): a) typically the D-Bus session will not see those and thus be unable to start any service described in them, thus things being broken b) there is no option to override any service files already found in system dirs before, D-Bus does a first-found-rules approach While for a) in typical distribution setups as user one can deploy D-Bus service files to ~/.local/share (like when session D-Bus is configured with <standard_session_servicedirs /> which results in XDG_DATA_ROOT dir being checked, which in the system usually is not set (remember, user configs are not read here), thus resolves to default ~/.local/share), this does not help with b) in case one wants to work on an app/service also installed to the system, as the D-Bus service files hard-code the binary path. YOUR INPUT NEEDED So, what standard approach should we take as developers here? Ideally we all do something similar, so any issues hit are more easy to understand/reproduce when we discuss them. The goal should be to add the recommended approach to the developer documentation and make any build tools (like kdesrc-build) also deal with that as much as possible. No own proposal here, only found out about the challenge now (even if it seems as old as D-Bus is). Cheers Friedrich
