On Wed, 27 Jul 2016 at 23:48:42 -0700, Josh Triplett wrote: > I can think of another reason that this might change: if we introduce an > (experimental, and eventually non-experimental) variant based on a > future stable version of kdbus.
The usual difficulties of depending on kernel features aside, I would hope that that would just be dbus-user-session, operating in a faster mode. There are two main reasons why dbus-user-session isn't just part of dbus: * it changes the semantics of the session bus, from per-login-session to per-user-session * it depends on systemd I haven't seen any proposals for kdbus that don't share both of those properties, and the version that was prototyped in systemd using an out-of-tree kernel module behaves a lot like dbus-user-session. (In fact, that prototype led to some of the motivations for dbus-user-session: getting some of the nice properties of the systemd kdbus prototype without needing kernel support, and getting implementation experience/fixing compatibility issues with the user-bus semantics *before* kdbus arrived, so that moving to kdbus wouldn't be such a huge "break the world" flag day.) > If we need to go through this transition anyway, could we please go > ahead and introduce a dbus-session-bus package for other packages to > depend on, to allow for potential future transitions or experiments? Do you think that's a worthwhile use of a Packages entry, even if we come to the conclusion that only desktop environments are expected to depend on it, and random apps that rely on it (like Empathy) are just expected to assume its presence? (See my reply to Laurent) S