Hello Simon,
On Fri 29 Oct 2021 at 11:12AM +01, 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)
>
> Proposed wording attached.
Thank you for this, sounds good to me.
virtual-package-names-list.yaml says that proposed new virtual package
names are meant to be sent to d-devel, not just filed as a bug against
debian-policy, so perhaps you could do that and we'll give it a week,
then I'll go ahead and add these?
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature