Bug#998063: debian-policy: New virtual package: {default-,}dbus-system-bus
On Fri, 29 Oct 2021 at 12:40:34 +0200, Adam Borowski wrote:
> On Fri, Oct 29, 2021 at 11:12:03AM +0100, Simon McVittie wrote:
> > * dbus, the portable reference implementation
> > * dbus-broker, a Linux-specific reimplementation
> >
> > so it seems like a good time to introduce {default-,}dbus-system-bus
> > virtual packages, mirroring {default-,}dbus-session-bus.
>
> > * default-dbus-system-bus | dbus-system-bus:
> > the well-known system bus, as required by e.g. Avahi, polkit, udisks2
>
> I wonder, perhaps it would be better to hijack the name "dbus", renaming
> the current bin:dbus package? That'd allow avoid changing around a hundred
> packages.
"Depends: dbus" implies all the functionality of what's now referred
to as dbus-system-bus, dbus-bin and dbus-daemon, which is a strict superset
of what I am proposing that dbus-system-bus implies. Packages with
Depends: dbus have always been able to assume that they can run dbus-send,
or dbus-run-session, or dbus-daemon, among other executable entry points,
but dbus-system-bus does not guarantee that functionality.
We should not require reimplementations like dbus-broker to provide
(or more likely, depend on) dbus-daemon(1), dbus-send(1) and all the
other executables that "Depends: dbus" has historically given you.
This is not a "hard" transition, and I don't think changing those packages
will ever need to be RC: dbus-broker and dbus can coexist (dbus-broker
will "win" in this case), so the worst-case scenario is that an excessive
dependency wastes some disk space.
Some of the packages that depend on dbus could benefit from some review
anyway, because some of them seem to be GUI applications for which
the dbus package is neither necessary nor sufficient: packages like
rhythmbox and evolution probably don't strictly need the system bus, but
probably *do* need the well-known session bus (represented by
default-dbus-session-bus | dbus-session-bus, as implemented by
dbus-user-session | dbus-launch) which is not implied by dbus.
smcv
Reply to: