Provide suitable configuration and install logic for use without dbus

[nolange]

Hello,

currently I need to create the following files to get a dbus-broker-only system working:

/usr/share/dbus-1/session.conf
/usr/share/dbus-1/system.conf
/usr/lib/systemd/system/dbus.socket
/usr/lib/systemd/system/sockets.target.wants/dbus.socket

it would be nice if the package either

• provided suitable default to run without configuration files
• or provide the config files, with an option to install them.

Similarly, an option for installing the systemd units would be welcome.

[dvdhrm]

Yeah, maybe you are right and it is time we provide these as well.

The reasoning so far was that the dbus-broker repository is about the dbus-broker executable, which is a self-contained, standalone bus implementation. It has no real interaction with the outside, no configuration parsing, etc.

However, to allow drop-in replacement for dbus-daemon, we did write dbus-broker-launch, and for convenience, we include it in the repository. It is meant to provide near-perfect compatibility to the reference implementation, and as such also uses the recommended configuration of the reference-implementation. We also argued that the right thing is to fetch all required resources from the reference implementation, so we are forced to stay compatible.

I do agree, however, that it seems beneficial to provide our own configuration, possibly tailored for dbus-broker with our recommended settings applied. I am not entirely sure this is the right way to go, because it also means we would now test 2 different configurations, and we actually would prefer if distros would provide the configuration adjusted to their own needs. But then again, this might be too much wishful thinking.

Lastly, regarding the unit installation: I am not so convinced this is the right thing. I actually like when distributions copy these manually to the place they need it. Maybe we should better document what is expected where?
The problem with making meson copy the files is that we need to support all kinds of parameters, need to be aware that people change them, etc. And at the same time, we don't care at all where those files are placed, as long as the distribution makes sure systemd picks them up.

Mh, I am open for arguments in both cases. I think the strongest argument for including both your suggestions is to make dbus-broker-launch more self-contained and less reliant on the reference-implementation.

Comments?

[nolange]

My use case would be some embedded linux installation, I need just enough dbus to get some systemd functionality working.
(some rather outdated attempt: https://github.com/nolange/buildroot/commits/add_dbusbroker)
I am not that familiar with dbus, other than whats necessary to make stuff work.

• There seems to be alot options in the dbus-reference implementation that's not needed or not supported
• Probably you could drop the dbus system user altogether? I believe systemd's isolation does anything a "user jail" does and then some. Even if not, systemd could create a nonpersistent dbus user for the service unit.
• Perhaps make using builtin defaults explicit, like via a --use-builtin-config=[no,yes,only] switch. That way you would behave like the reference and fail if settings are missing or incomplete (no), use sane defaults that can be extended/overriden (yes) or config files are always ignored (only).

[bluca]

FYI in Debian and Yocto we followed the same model as Fedora, splitting up the dbus-daemon package into multiple components, some of which only have the config bits and are shared. That allows us to keep them in sync, and keep us honest about cross-compatibility.