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
_______________________________________________
Pkg-utopia-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
