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

[James Clarke]

On 17 Oct 2017, at 15:12, Simon McVittie <smcv at debian.org> wrote:
> 
> 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.

It seems to me from looking at that thread that the main reason for using a
virtual package is that it's simpler. The example given was for the default
MTA, which works because Debian has the same default across all architectures,
but for something like this it isn't so simple and you then have to mess about
with spreading the Provides across different packages and making them
conditional, rather than just a single meta-package with the relevant
conditional Depends in one place.

>> 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?

They could, but then the resolvers differ across architectures, and that will
likely cause its own set of confusing problems. I'm not aware of many cases
where using apt has been a problem like this, though I could be wrong.

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

OpenCV currently suffers from this[0] (hence why Mattia is Cc'ed).

Thanks,
James

[0] https://buildd.debian.org/status/fetch.php?pkg=opencv&arch=kfreebsd-amd64&ver=3.2.0%2Bdfsg-2&stamp=1508228257&raw=0
    (tried 4 times on kfreebsd-i386 and kfreebsd-amd64 so far... it's a shame
     wanna-build's use of dose-builddebcheck doesn't match apt's behaviour)