Sending this to -devel since Sean pointed out that new general-purpose
virtual package names are meant to go there, not just to a Policy bug.

On Fri, 29 Oct 2021 at 11:12:07 +0100, Simon McVittie wrote:

We now have two implementations of the D-Bus well-known system bus
available in Debian:

* 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.

At the moment, dbus is the default for all architectures. It is possible
that dbus-broker might take over as the default on Linux architectures
in some future release (but it is explicitly not portable, so dbus will probably always be the default on kFreeBSD and Hurd, similar to how we
choose dbus-user-session vs. dbus-launch).

Packages depending on "dbus" can currently count on having most aspects of the reference implementation available (except for the session bus, which requires either dbus-user-session or dbus-launch), but I would prefer to
move towards packages explicitly declaring a dependency on one or more of:

* default-dbus-system-bus | dbus-system-bus:
the well-known system bus, as required by e.g. Avahi, polkit, udisks2

* dbus-daemon: ability to run the dbus-daemon(1) and dbus-run-session(1)
executables, or rely on having the D-Bus machine ID /var/lib/dbus/machine-id
(dbus-session-bus and dbus-system-bus both imply some sort of machine
ID, but it might be systemd's /etc/machine-id)

* dbus-bin: ability to run assorted CLI tools such as dbus-send(1) and
dbus-monitor(1)

A patch against Policy can be found on https://bugs.debian.org/998063,
but the important content is:

- name: dbus-system-bus
description: provides the D-Bus well-known system bus as a system service, including service activation
- name: default-dbus-system-bus
description: Debian's preferred implementation of dbus-system-bus, possibly architecture-specific

This split is already implemented in bookworm, and a few packages already depend on the new virtual package names.

dbus in bullseye had a Provides: for default-dbus-system-bus,
dbus-system-bus, dbus-daemon and dbus-bin in preparation for the split,
so this dependency change can safely be backported from bookworm to bullseye-backports without changes (but will need to be reverted in the
rare case of a backport from bookworm to buster-backports-sloppy).

On the Policy bug, Adam Borowski queried whether it would be better to repurpose the dbus package name as the virtual package and use a new
package name for the reference implementation, similar to the way the
sysvinit package name was repurposed to mean "an init system" during the transition to systemd, with the real SysV init renamed to sysvinit-core. I think this would not have been correct, because packages that depend on
dbus have historically been able to rely on the combined functionality
of what we're now calling dbus-system-bus, dbus-daemon and dbus-bin,
and should continue to be able to do so.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)