[Pkg-utopia-maintainers] Bug#878878: default-dbus-session-bus: Not installable on non-Linux

[Simon McVittie]

Control: tags -1 confirmed pending
Control: severity -1 wishlist

On Tue, 17 Oct 2017 at 13:41:31 +0100, James Clarke wrote:
> Please modify dbus, either with more complicated Provides

This requires dbus-user-session to become Architecture: linux-any
instead of all (lots of duplicate per-Linux-architecture copies of
the same thing), but at least it doesn't involve going through NEW,
and arguably making it linux-any is more correct. In principle I'm OK
with doing this, although I'll need to try a build on a porterbox to
check I've done the architecture specifier syntax correctly.

It's a pity we don't have a way to express "this is
architecture-independent, but should only appear in a subset of the
apt Packages files". If we did, dbus-user-session could be
"all [linux-any]" or whatever the syntax was, and continue to provide
d-d-s-b.

Alternatively, I'd review patches if someone wants to teach
dbus-user-session how to support non-systemd, although that would almost
certainly mean someone writing a PAM module to do the work (an alternative
to libpam-systemd) and being its upstream and Debian maintainer. Sorry,
I'm not willing to maintain that part, only "glue" analogous to what's
already in the package for systemd.

The design requirements for dbus-user-session are:

* one `dbus-daemon --session` per uid
* after the PAM login stack has run, either or both (preferably both):
  - XDG_RUNTIME_DIR must be set to a unique directory per uid on a
    tmpfs (or non-Linux equivalent) with a listening socket at
    $XDG_RUNTIME_DIR/bus
  - DBUS_SESSION_BUS_ADDRESS must be set to the right thing
* connecting to the given address must result in a connection to the
  `dbus-daemon --session` (it can be started lazily with socket
  activation, like systemd does, or eagerly, like dbus-launch does)
* after the PAM logout stack has run, if and only if this was the uid's
  last parallel login session, the dbus-daemon should be terminated
  and the XDG_RUNTIME_DIR should be deleted

In systemd-land, pam_systemd (which is misnamed, it's really part of
logind) notifies logind about the login/logout, logind creates/destroys
the XDG_RUNTIME_DIR if this is the first login/last logout, logind tells
systemd-as-pid-1 to start `systemd --user` if this is the first login or
stop it if this is the last logout, and `systemd --user` loads the
dbus.socket and dbus.service provided by dbus-user-session.

Ubuntu used to have a PAM module to set up and tear down XDG_RUNTIME_DIR,
but they were its upstream, so now that they use systemd-logind it's
unmaintained.

> or by making default-dbus-session-bus an actual
> meta-package

When I proposed (default-)dbus-session-bus I was told not to use a
real package, for reasons that were never particularly clear to me.
(Thread: <https://lists.debian.org/debian-devel/2016/07/msg00484.html>,
related Policy bug documenting the metapackages:
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833401>)

If I had used real packages, the real package would have been
dbus-session-bus, which would have had alternative dependencies
on dbus-user-session | hypothetical-future-kdbus-thing | dbus-x11
(with [linux-any] scattered around where appropriate). However,
the virtual package approach has been widely adopted now, so I'll
go the other way.

> This has recently become a problem because dconf-service
> 0.26.1-1 now depends on default-dbus-session-bus | dbus-session-bus,
> making it uninstallable on the buildds for non-Linux unless their build
> deps happen to have something else depending on dbus-session-bus (or
> dbus-x11).

I can't help wondering whether the non-Linux ports should configure their
buildds to use the aptitude dependency resolver (as used in -backports)
or the aspcud resolver (as used in experimental) to get out of this
situation. Surely this can't be the first time this has happened?

Can you point me to an example of buildd logs where the Linux build
succeeded and !Linux builds failed as a result of this?

    smcv