Bug 20099 - ability to add activation directories later
Summary: ability to add activation directories later
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.5
Hardware: All All
: medium enhancement
Assignee: D-Bus Maintainers
QA Contact: D-Bus Maintainers
Depends on:
Reported: 2009-02-13 07:54 UTC by Colin Walters
Modified: 2018-10-12 21:05 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Description Colin Walters 2009-02-13 07:54:14 UTC
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.


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.
Comment 1 Chengwei Yang 2013-09-27 07:06:11 UTC
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.
Comment 2 Rex Dieter 2013-09-27 13:45:26 UTC
Suggesting conflicting packages isn't a viable long-term solution (and are a packaging policy violation for some distros, including fedora).
Comment 3 GitLab Migration User 2018-10-12 21:05:49 UTC
-- 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.