[ sorry for the late reply, was busy $irl]
On Mon, 06 Jul 2026 13:09, Simon McVittie <[email protected]> wrote:
Please send questions regarding D-Bus to [email protected] rather than only to me personally: I don't want to be the single point of failure for D-Bus on Debian.
Right, will do so in the future.
Strictly speaking dbus is just the reference implementation of D-Bus (there can be others, like dbus-broker) but its package address seems like as good a coordination point as any other.Thanks for clarifying. Afaik the pam bits are done by pam-openrc, and the other bits are (mostly) done by the yet-to-be-uploaded dbus-user-session-openrc package.On Tue, 30 Jun 2026 at 16:21:41 +0200, Matthias Geiger wrote:What is the purpose of dbus-user-session? As far as I understand, this is *not* the plain dbus sessionIt was a new concept at the time it was introduced, but is now the default and the setup that I would recommend. The other D-Bus session bus implementation with OS-level integration is dbus-x11, which only works for X11 sessions (not for Wayland, text consoles, ssh, etc.).*Right now*, the dbus-user-session package only implements this design for systemd systems (more precisely, systems with a working `systemd --user`, which is a subset of systems with systemd as pid 1), but there's nothing to stop non-systemd system designs from doing the same, and I've seen that dbus-turnstile-user-session and runit-dbus-user-session seem to work similarly. I'd recommend the same "shape" that is used with systemd:* XDG_RUNTIME_DIR set to /run/user/$(id -u) like systemd-logind does (some software hard-codes this, even though in principle it shouldn't, and the path chosen by systemd-logind is as good as any other) * a PAM module runs on login/logout and starts or communicates with some sort of service manager (in systemd-world this is libpam-systemd and `systemd --user`, other service managers presumably have something fairly similar) * the service manager arranges for a dbus-daemon (or dbus-broker or some other message bus implementation) to be listening on $XDG_RUNTIME_DIR/bus, before the startup of anything else that needs it (or it could listen on the socket itself, with an inetd-style arrangement like the LISTEN_FDS protocol and start the dbus-daemon on a just-in-time basis, which in fact is what systemd does) * the PAM module sets DBUS_SESSION_BUS_ADDRESS to point to unix:path=$XDG_RUNTIME_DIR/bus (with URI-style quoting/escaping as per the D-Bus spec if necessary, but one of the reasons to reuse the path chosen by systemd-logind is that it happens to be one that won't need any quoting/escaping)
but rather where a user session is assumed to start the first time after login, and it doesn't end until all login sessions have ended. It also provides dbus-services with XDG_RUNTIME_DIRAll of those are key features of dbus-user-session, yes.More precisely, this is about D-Bus *session* services. D-Bus system services are also a thing that exists (NetworkManager, etc.) but they're orthogonal to all this session-level stuff.dbus-user-session also (via /etc/X11/Xsession.d/20dbus_xdg-runtime) provides activatable D-Bus session services with some other key X11/freedesktop.org environment variables, notably $DISPLAY.
Ah, right.
I agree that for the time being, especially since this is new, we want to keep the alternative provides until we have a more polished openrc experience. This dbus package is also essential if users want to start openrc user services.But, one thing that it *doesn't* do:and runs dbus-activation-enviroment --allNo, that's /etc/X11/Xsession.d/95dbus_update-activation-env in dbus-x11, which I see as being a backward-compatibilty thing to cope with the fact that older Xsession.d snippets might rely on merely doing `export FOO` being sufficient to have FOO in the environment of D-Bus-activated services like xdg-desktop-portal. (For example I think some non-Latin input methods might still be relying on this, via im-config?)I think that a high-quality Xsession.d snippet should either not need to set environment variables at all (relying instead on components discovering each other via $XDG_RUNTIME_DIR, $HOME, D-Bus, X11/Wayland or similar), or if new environment variables are really needed, take responsibility for uploading them to the D-Bus/systemd/etc. activation environment itself.Environment variables are not a great discovery/advertising mechanism because of how they inherit between processes: an environment variable can never be "instant-apply", because existing processes will already have inherited its old value and are not notified when it gets a new value. For example, this is why we can't have instant-apply locale settings: with hindsight, the POSIX environment variables used for locales are not a great design. Systems like $XDG_RUNTIME_DIR, $DBUS_SESSION_BUS_ADDRESS and even $DISPLAY solve this by adding a layer of indirection. The $XDG_RUNTIME_DIR doesn't need to change during a program run, because it doesn't do anything particularly human-meaningful on its own; but the sockets or files in the directory that it points to, the information exposed by D-Bus services or Xsettings, etc. are human-meaningful and *can* change at runtime.On Tue, 30 Jun 2026 at 16:00:55 +0100, Mark Hindley wrote:Simon, for completeness, I am aware of at least 3 potential packages that now provide the systemd-style supervisor + unified dbus session: dbus-openrc-user-session (pending upload) dbus-turnstile-user-session runit-dbus-user-session Obviously they should Provides: dbus-session-bus. However should they also Provides/Conflicts: dbus-user-session?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, ...(This is a bit more complicated in reality because there are several systemd-related dependencies, so those alternatives would need to be added in more than one place, but you get the idea - and perhaps dbus-user-session doesn't need to be so pedantic about its dependencies anyway, now that systemd as pid 1 has been the default for several release cycles and the only systems not using it will be those where a different init was intentionally chosen.)Or, if one of those alternative service managers becomes a widely-used, cross-distro, de facto standard with a long-term-stable API and a systemd-unit-equivalent that is low-maintenance over time (as systemd itself did, and Upstart nearly did), then dbus upstream and dbus-user-session could absorb those systemd-unit-equivalents and install them alongside the systemd units that they currently ship, so that systemd systems would run the systemd unit, OpenRC systems would run whatever OpenRC's equivalent is, and so on, and everyone would be happy. I'm not sure that any of the alternatives have that status yet, though, so installing them in separate packages with an alternative dependency is probably better at the moment - that gives the alternative service managers' maintainers more control over the precise details of how they start a D-Bus session bus, and more ability to experiment with improving those details.
Having had this design in mind is why the package is called dbus-user-session, and not dbus-systemd-user-session or something.If that was implemented, then I'd expect "most" system designs to have dbus-user-session installed: systemd users would have dbus-user-session and libpam-systemd, resulting in `dbus-daemon --session` being started as a `systemd --user` service, while OpenRC/turnstile/runit users would instead have dbus-user-session and their appropriate service manager glue, resulting in `dbus-daemon --session` being started as their service manager's closest equivalent of a `systemd --user` service.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, unless we moved that file into dbus-session-bus-common (which could be practically annoying, because it's a dpkg conffile and I'm never sure what manipulations are/aren't safe to be doing with conffiles).I don't think a Conflicts with dbus-user-session is desirable or necessary. The only thing in dbus-user-session that could cause a problem for alternative service managers is its dependency on systemd, which could be expanded into a set of alternative dependencies that covers other implementations of the same "API": the actual systemd unit files should be inert and useless-but-harmless on non-systemd systems, similar to how (for example) the runit glue in openssh-server is useless-but-harmless on systemd systems.It would be good to agree a naming convention as well.I think a good rule of thumb is that if a package "belongs to" or "is part of" a particular upstream, having that upstream project's name as a prefix makes more sense than having it as an infix. So I like the naming of runit-dbus-user-session better than dbus-openrc-user-session, for a project that is maintained by runit/openrc developers and not by the developers of dbus.
Right, that makes sense, too. So it'd be openrc-dbus-user-session. Thanks for all the insights! @Mark: Do you agree with the naming and Provides:? best, werdahias
signature.asc
Description: Digital signature
_______________________________________________ Pkg-utopia-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
