Bug#1122564: elogind: directly Depends and Build-Depends on dbus

[Simon McVittie]

On Fri, 12 Dec 2025 at 09:51:10 +0000, Mark Hindley wrote:
>Surprisingly (to me, at least) and contrary to the upstream documentation,
>removing Build-Depends: dbus seems to make no difference to the packages:

At a guess, the upstream documentation is probably assuming that all of 
src:dbus (including libdbus-1-dev) is treated as a monolithic unit, as 
it would be in a source-based distro like Gentoo, or a binary distro 
that splits packages less enthusiastically than we do, like Arch?

In Debian, the dbus binary package specifically means: we are using the 
reference implementation of D-Bus (namely src:dbus) to provide the 
well-known system bus. Smaller subsets of src:dbus are in other binary 
packages like dbus-daemon, dbus-bin and libdbus-1-3.

The most common reason to need executables from dbus at build-time is to 
run unit tests on a temporary instance of the message bus 
(dbus-run-session(1), dbus-daemon(1), GTestDBus, dbus-test-runner or 
similar). If elogind doesn't do this, then it's entirely reasonable for 
it not to benefit from the dbus package.

elogind is a D-Bus system service like systemd-logind and polkitd, so 
it certainly does need a D-Bus system bus *at runtime*, but the presence 
or absence of a system bus at build-time has no real bearing on that - 
and a build-dependency on dbus can't actually guarantee a working system 
bus at build time anyway, because build chroots/containers often use a 
policy-rc.d to avoid starting system services even if they are installed.

Because it's a fork of systemd-logind, it's likely that elogind is using 
using (a fork of) systemd's own implementation of the D-Bus protocol (in 
systemd it's called sd-bus(3), I don't know whether elogind has renamed 
it internally) and therefore doesn't need the reference client library, 
libdbus.

sd-bus(3) is one of the better-quality D-Bus implementations, and 
libdbus has some design and compatibility constraints that make it 
difficult to improve, so if elogind is using a fork of sd-bus that isn't 
necessarily a negative thing - "reference implementation" doesn't mean 
"best implementation".

>Looking in meson.build, the dbus dependency that is tested in dbus-1. This sets
>HAVE_DBUS, but I don't see that being used anywhere. So, my inclination is that
>this is cruft that can safely be dropped.

dbus-1.pc is in libdbus-1-dev. And, yes, if HAVE_DBUS is never tested, 
that's probably dead code.

>As for the runtime dependency, the current default-dbus-system-bus, dbus-broker,
>requires systemd-sysv and is therefore not installable with elogind.

dbus is still the default-dbus-system-bus, and dbus-broker is only an 
alaternative dbus-system-bus. I'm not aware of anyone advocating 
changing the default, and I don't intend to advocate it myself: this 
dependency change is about making it possible to have non-default system 
bus implementations, rather than about changing the default.

If dbus-broker (or something else) does become the 
default-dbus-system-bus at some point in the future, the benefit of the 
setup with virtual packages is that a Debian derivative would be able to 
switch the default back to dbus in one place if it wanted to, rather 
than having to go around changing dependencies in all of the dependent 
packages individually. This is similar to the arrangement with the 
default-logind and logind virtual packages.

If we gained a third implementation of a D-Bus message bus at some point 
in the future, that would also be a dbus-system-bus (and possibly become 
the default, depending whether it seemed better for typical systems than 
dbus and dbus-broker). This is a theoretical benefit right now, but 
having consistency across the distribution seems desirable.

     smcv