Simon, On Sun, Aug 23, 2026 at 02:12:34PM +0100, Simon McVittie wrote: > 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.
Thanks. Currently there is native support for user sessions in openrc and runit. Turnstile is completely init-agnostic, but given that native support is available in openrc and runit, its likely usage is with sysvinit. That seems to cover all the current users and I don't envisage the need for additional implementations. > 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`. I envisage that utrans will generate the relevant scripts from the installed systemd units. Whilst the generated scripts are not as lean as you might write by hand and inherit systemd approaches such as socket-activation[1], in general they work and it removes the need for packages to ship support other user services implementations. This leaves only those few scripts that don't translate well requiring manual attention and packaging. The only significant unit I am aware of currently that cannot be translated is user/dbus.service as it specifies the systemd specific --address=systemd:. This explains why dbus is the only user service shipped in openrc-dbus-user-session and dbus-turnstile-user-session. The utrans openrc backend already has support for user services. I also have a backend for turnstile completed and pending upload. I would be happy to accept a runit backend when/if Lorenzo or somebody else wishes to contribute one. > 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? I think they are all WIP at the moment as we navigate the finer details. But I hope forky will include .. | openrc-dbus-user-session | runit-dbus-user-session | turnstile-dbus-user-session Openrc upstream is still finalising aspects of environment activation and RC_PATH that we expect to be released in 0.64. > 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). I will look at these aspects this week. I will also rename dbus-turnstile-user-session to turnstile-dbus-user-session to fit with our recently agreed naming system. That will obviously require traversal of NEW, but that is refreshingly quick at the moment. > 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? Yes, pam_turnstile exports DBUS_SESSION_BUS_ADDRESS and XDG_RUNTIME_DIR. The rest of the environment is inherited from the normal terminal/graphical login. Best wishes and thanks again. Mark [1] Handled by src:sasa _______________________________________________ Pkg-utopia-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
