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
