Source: https://bugzilla.redhat.com/show_bug.cgi?id=484945 The summary is that both KDE and GNOME would like to be able to provide an implementation of the service "org.gnome.PolicyKit". If dbus was started by the desktop environment, then it could have full control, but this is an inversion problem similar to the one motivating the already extant SetActivationEnvironment bus method. Proposals: 1) Add a bus method org.freedesktop.DBus.AddServiceDirectory(s) with obvious semantics 2) Go the full general route and do org.freedesktop.DBus.ParseConfig(s) which takes a fragment of bus configuration format.
I think this is a wontfix, just my points as below. The system bus activation will has a new feature that do deterministic activation, see #bug66608, that means: 1. the .service named after its well-known name, for example, com.example.foo.service must owned com.example.foo. So there is no more than one .service file own the same well-known name. 2. since the servicedir loading sequence is deterministic from bus .conf, so it's determinable which service will be activated. For user session bus activation, it's undeterminstic as before, bug a simple solution I can tell is why not mark packages conflict if they're provides the same dbus service? Or virtual package? I think dbus isn't the one to handle such a out of scope corner case.
Suggesting conflicting packages isn't a viable long-term solution (and are a packaging policy violation for some distros, including fedora).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/17.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.