On Wed, 27 Jul 2016 at 18:02:32 +0200, Laurent Bigonville wrote: > Is that really up-to the individual application to declare a dependency > against dbus-user-session | dbus-x11 ?
At the moment: yes. A dependency on dbus-x11 (in jessie) or on dbus-user-session | dbus-x11 (now) can be used to signify "this application or library is useless without a working session bus". Apps that rely on Telepathy, Tracker or the Evolution servers are good examples of a legitimate dependency on the session bus. Depending on dbus is not enough: that only guarantees working D-Bus binaries (so you have all the right bits to get a session bus, but some assembly is required) and a working system bus. The only other ways I can think of right now to express that requirement are: * introduce a metapackage "dbus-session" with that dependency, and ask these apps to depend on it, or on dbus-session | dbus-x11 to be nice to backports; * give up on it entirely, and consider a working D-Bus session to be an essential/assumed part of desktop environments (like a working X11 server is), with a policy that only desktop environment tasks need to declare the dependency, and random apps can just assume it (Arguably we already have this situation; I'm sure there are lots of apps that don't declare this dependency but are unusable without D-Bus because they rely on GApplication, fd.o Notifications or some other piece of infrastructure that relies on the session bus.) > If the package name is changing or if we are dropping dbus-x11 in the future > that would require modifying again quite some packages. I currently count 55 direct Depends and 17 Recommends on dbus-x11, to give you an idea of the number of packages involved. The last time this changed was the introduction of dbus-x11 in 2007; twice in a decade isn't bad. I don't think it's necessarily going to change again any time soon (unless we do a transition to dbus-x11 | dbus-user-session and then another to dbus-user-session | dbus-x11, which is why I'd prefer not to do that two-stage approach). If we drop dbus-x11 at some point in the future, or even fold dbus-user-session into dbus, those packages won't need modification: as long as either dbus-user-session still exists, or dbus Provides it, those packages are still Policy-compliant (I believe we only require one branch of an "or"-group to be available in main). In practice I don't think this is going to happen any time soon, for the reasons mentioned under "Why should dbus-user-session be optional?" in my original mail. > Shouldn't this > dependency only be declared at some other level (libdbus, GDBus,...)? I think this would have to be a new dbus-session metapackage, unless I'm missing something. dbus is the wrong place, and so are all the obvious libraries. dbus Suggests dbus-user-session | dbus-x11 already. Anything stronger than Suggests seems inappropriate because it would be a circular dependency (dbus-user-session and dbus-x11 both need dbus, for dbus-daemon). libdbus-1-3 shouldn't depend on a session bus, because you might only be using it to access the system bus; conversely, you might be using a different implementation like GDBus or sd-bus or dbus-java and you'd still be missing the dependency. It would also be a circular dependency, via dbus (dbus Depends libdbus-1-3 Depends (dbus-user-session|dbus-x11) Depends dbus). libglib2.0-0 (which contains libgio-2.0.so.0, which contains GDBus) shouldn't depend on a session bus for reasons analogous to libdbus-1-3's, and also your uses of GLib might not involve D-Bus at all (perhaps it's just installed for irssi's benefit). libsystemd0 (which contains sd-bus) definitely must not depend on dbus, because dbus depends on it (circular dependencies again), and because it's transitively Essential (via util-linux). S