[Pkg-utopia-maintainers] dbus-sesssion questions

[Simon McVittie]

On Tue, 18 Aug 2026 at 18:02:52 +0100, Mark Hindley wrote:
>On Tue, Jul 14, 2026 at 12:29:05PM +0200, Matthias Geiger wrote:
>> > The way I had originally anticipated that this would work, when I
>> > introduced dbus-user-session, is that dbus-user-session could have
>> > alternative dependencies on anything that will arrange for the desired
>> > semantics to exist, so perhaps like this:
>> >
>> >     Depends:
>> >      libpam-systemd | dbus-openrc-user-session | dbus-turnstile-user-session | runit-dbus-user-session,
>> >      ...
>
>Do you mind the workload of maintaining that in dbus?

That depends how many implementations there are going to be, and how 
quickly we'll gain them. If it's one every few months or years and 
old/obsolete/not-recommended implementations can be cleaned up 
periodically, with the non-default-init community choosing a smallish 
number of recommended technologies to get behind, then that seems fine. 
If they proliferate rapidly, then I'd rather not.

I think it would provide the best experience for the non-default-init 
community if there was a reasonably clear recommendation for what user 
session implementation is recommended for those who prefer not to use 
`systemd --user`.

If some of these implementations are recommended for general use and 
others are experimental/bleeding-edge/known-broken, then it's probably 
best for dbus-user-session to only accommodate the recommended ones in 
its alternative dependency or-group. What would those be?

>> > The other way this could potentially work would be for these other
>> > implementations of a "user bus" to have a Provides for dbus-session-bus
>> > and dbus-user-session, meaning that systemd users would have
>> > dbus-user-session + libpam-systemd, but e.g. runit users would only have
>> > runit-dbus-user-session (and *not* dbus-user-session). However, that
>> > would mean that these other packages would need to duplicate what
>> > /etc/X11/Xsession.d/20dbus_xdg-runtime does,
>
>This appears to be less work for you?  Whilst there may be some duplication, it
>also allows individual implementations to adapt the Xsession.d hook to their
>specific requirements.

I see that dbus-turnstile-user-session and openrc-dbus-user-session 
currently conflict with dbus-user-session. Could they avoid doing that? 
That would allow either installing dbus-user-session (if its 
alternative dependencies are expanded to accommodate the non-systemd 
implementations), or not (if the non-systemd implementations provide 
their own equivalent of 20dbus_xdg-runtime).

The "reference copy" of 20dbus_xdg-runtime in dbus is intended to be 
something that's safe to exist whether we're using systemd-logind or 
something else, and idempotent: it only sets DBUS_SESSION_BUS_ADDRESS 
if:

- it isn't yet set
- && the $XDG_RUNTIME_DIR is set to the path we expect
- && $XDG_RUNTIME_DIR/bus exists

which seem like things that should be harmless to do under any 
implementation. Similarly, it only uploads known-desirable environment 
variables into the D-Bus (and/or systemd) activation environment 
(DBUS_SESSION_BUS_ADDRESS, DISPLAY, XAUTHORITY, XDG_CURRENT_DESKTOP), 
and doesn't upload random other environment variables that might or 
might not be appropriate: it errs on the side of only doing the things 
that we know are genuinely necessary.

Could openrc-dbus-user-session perhaps install something similar as 
20openrc-dbus-user-session instead of as 20dbus_xdg-runtime? And then 
they'd be able to coexist (with some harmless redundancy).

dbus-turnstile-user-session seems to install its own 
/etc/X11/Xsession.d/89turnstile-suss-env and avoid overwriting 
/etc/X11/Xsession.d/20dbus_xdg-runtime. Do I assume correctly that it 
has its own way (PAM module?) to get an appropriate 
DBUS_SESSION_BUS_ADDRESS, DISPLAY, XAUTHORITY and XDG_CURRENT_DESKTOP 
into the activation environment?

Currently the only other things in dbus-user-session are systemd units, 
which are unnecessary-but-harmless on systems that don't use `systemd 
--user`.

     smcv