[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#833401: debian-policy: virtual packages: dbus-session-bus, dbus-default-session-bus

Package: debian-policy
Severity: wishlist
X-Debbugs-Cc: debian-devel@lists.debian.org

I propose two new virtual packages:

dbus-session-bus: anything providing the D-Bus well-known session bus
for user login sessions

dbus-default-session-bus: Debian's preferred implementation of

Currently, many packages that require a D-Bus session bus express that
dependency by depending on dbus-x11. Many more packages rely on a session
bus without an explicit dependency. I would like to deprecate dbus-x11
(which provides a D-Bus session bus per X11 session to that X11 session)
in favour of dbus-user-session (which provides a D-Bus session bus per
uid, shared by all concurrent PAM sessions), while keeping dbus-x11
supported as a non-preferred implementation.

>From discussion in the related MBF plan
<https://lists.debian.org/debian-devel/2016/07/msg00484.html>, I am led
to believe that the preferred way to do this is with two virtual packages,
analogous to mail-transport-agent and default-mta.

dbus-session bus would be provided by dbus-x11, dbus-user-session, and
possibly something kdbus-related in future. The intended semantics are:
programs in at least graphical login sessions can rely on seeing the
$DBUS_SESSION_BUS_ADDRESS environment variable, the $XDG_RUNTIME_DIR/bus
Unix socket, or some other way to discover a session bus that is supported
by all the major D-Bus client libraries.

dbus-default-session-bus would be provided by exactly one package per suite
that is the preferred implementation, currently dbus-user-session.

Programs and desktop environments that require a D-Bus session bus and cannot
work without one should generally declare:

    Depends: dbus-default-session-bus | dbus-session-bus

Programs with weaker dependencies can use a Recommends or a Suggests.

Other options

If this is not a best-practice use of virtual packages, the other options that
I am aware of are:

* Add a real (non-virtual) empty package dbus-session-bus built by src:dbus,
  with Depends: dbus-user-session | dbus-x11 (initially). Other packages
  depend on dbus-session-bus.
  (Pro: simpler dependency graph. Con: requires NEW queue.)

* Add a virtual package dbus-session-bus, and a real (non-virtual) package
  dbus-default-session-bus built by src:dbus.
  (Pro: avoids ambiguity if apt is configured to see more than one suite.
  Con: requires NEW queue.)

* Give packages a direct Depends: dbus-user-session | dbus-x11, and do
  another MBF if we decide post-stretch that we should actually be
  preferring a third implementation, kdbus-session-bus or something.
  (Pro: no proliferation of package names. Con: possible MBF in future.)

* MBF asking applications to stop depending on dbus-x11, and just
  assume that any reasonable desktop environment will pull in
  dbus-user-session | dbus-x11 anyway, in the same way that applications
  are not expected to depend on an X11 server.
  (Pro: simplest possible dependency graph. Con: undeclared dependency.)


Reply to: