On Fri, 2021-12-24 at 10:05 +0000, Simon McVittie wrote: > 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 > With my dbus-broker maintainer hat on, I fully agree with your proposal and reasoning w.r.t. package names. Thank you very much for your work! -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part