This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 484945 - D-Bus activation needs a way to prefer one service over the other depending on the running desktop environment
D-Bus activation needs a way to prefer one service over the other depending o...
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: dbus (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Colin Walters
Fedora Extras Quality Assurance
: FutureFeature
: 498867 1016828 (view as bug list)
Depends On:
Blocks: F11Target 519654 806539
  Show dependency treegraph
 
Reported: 2009-02-10 14:54 EST by Kevin Kofler
Modified: 2013-10-08 14:56 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 20099 None None None Never

  None (edit)
Description Kevin Kofler 2009-02-10 14:54:52 EST
Description of problem:
Currently, if 2 programs provide the same service, D-Bus activation just picks an arbitrary one:
http://cgit.freedesktop.org/dbus/dbus/tree/bus/activation.c
       /* FIXME we need a better-defined algorithm for which service file to
        * pick than "whichever one is first in the directory listing"
        */

This is a problem in cases like PolicyKit where desktop environments provide their own integration, i.e. PolicyKit-gnome and PolicyKit-kde.

We need a way to have PolicyKit-kde chosen in KDE and PolicyKit-gnome elsewhere automatically. If only one is installed, that one provider should be chosen.

Version-Release number of selected component (if applicable):
dbus-1.2.4.4permissive-1.fc11
(but this has been there ever since D-Bus activation exists and is not fixed in the D-Bus trunk yet either)

How reproducible:
Always

Steps to Reproduce:
1. Install PolicyKit-kde on a system with PolicyKit-gnome already installed.
2. Start KDE.
3. Start KPackageKit.
  
Actual results:
PolicyKit-gnome starts.

Expected results:
PolicyKit-kde starts.

Additional info:
We'd happily do the required changes in PolicyKit-kde, but we need D-Bus fixed. Or can you suggest a reliable workaround?
Comment 1 Colin Walters 2009-02-10 15:06:05 EST
Without modifying dbus, this could be handled by using two names.  First the "generic" name which in this case appears to be "org.gnome.PolicyKit", and the "implementation name" which could be org.gnome.PolicyKitGnome.

The desktop environment would be responsible for activating org.gnome.PolicyKitGnome on startup.

This does sort of remove the on-demand nature of things.

Another design is that dbus activation could support *one* "service prefix" which some other process (e.g. gnome-session) sets on it during startup.  During activation of a name org.foo.Bar, it would first try activating prefix/org.foo.Bar.
Comment 2 Kevin Kofler 2009-02-10 15:39:15 EST
I think the "service prefix" idea sounds like the best solution. How would this be implemented? By sorting the directory list so the services with the prefix come first? (It's an O(n) partial sorting, there just need to be 2 buckets.)
Comment 3 Colin Walters 2009-02-10 15:48:53 EST
I was thinking of subdirectories, i.e. /usr/share/dbus-1/services/GNOME/
Comment 4 Matthias Clasen 2009-02-13 00:44:17 EST
Can't you already do that, by having each desktop environment use its own dbus session.conf file, with an additional <servicedir> directive ?
Comment 5 Matthias Clasen 2009-02-13 00:46:58 EST
I guess it would just be


<include>/etc/dbus-1/session.conf</include>
<servicedir>/usr/share/dbus-1/services/GNOME</servicedir>
Comment 6 Kevin Kofler 2009-02-13 03:43:32 EST
How would we start D-Bus with that session.conf file? Isn't it started from common code for all X sessions? If it's the latter, I think we need to be able to change the settings with a message to a running D-Bus.

As for:
> <include>/etc/dbus-1/session.conf</include>
> <servicedir>/usr/share/dbus-1/services/GNOME</servicedir>
won't that still scan the default search dirs before the one you add there? I think we want the desktop-provided servicedir to take precedence, so we can have one default PolicyKit provider and individual desktop environments can override it. If you put PolicyKit-gnome under GNOME and PolicyKit-kde under KDE, other environments will be left with no PolicyKit support.
Comment 7 Matthias Clasen 2009-02-13 10:24:09 EST
Yes, you are right, currently the bus is started from
/etc/X11/xinitrc/xinitrc.d/00-start-message-bus.sh

According to the dbus-daemon man page the last specified servicedir is scanned first. Gotta love that...
Comment 8 Kevin Kofler 2009-02-13 10:34:34 EST
> Yes, you are right, currently the bus is started from
> /etc/X11/xinitrc/xinitrc.d/00-start-message-bus.sh

So that's the problem.
Is there any way we can inject a servicedir into a running D-Bus? If not, should there be one?
Alternatively, startkde can start D-Bus on its own:
> if test -z "$DBUS_SESSION_BUS_ADDRESS" ; then
>     eval `dbus-launch --sh-syntax --exit-with-session`
> fi
so maybe we should just have it kill the running D-Bus and restart it with the config file we want?

> According to the dbus-daemon man page the last specified servicedir is scanned
> first. Gotta love that...

Well, in this case it'd actually be what we want.
Comment 9 Colin Walters 2009-02-13 10:55:07 EST
Filed upstream, feel free to continue there: https://bugs.freedesktop.org/show_bug.cgi?id=20099
Comment 10 Colin Walters 2009-02-13 11:09:14 EST
Killing the bus is a bad idea because the reason it runs early is to let "early things" use it.
Comment 11 Matthias Clasen 2009-02-13 11:20:05 EST
Yeah, killing the bus is out of the question
Comment 12 Nils Philippsen 2009-03-02 03:38:38 EST
Sorry for coming late...

(In reply to comment #1)
> The desktop environment would be responsible for activating
> org.gnome.PolicyKitGnome on startup.

This would lead the whole "service shall be started on demand in order to not waste resources or add to startup time" thing ad absurdum, wouldn't it?
Comment 13 Matthias Clasen 2009-05-04 12:27:50 EDT
*** Bug 498867 has been marked as a duplicate of this bug. ***
Comment 14 Toshio Ernie Kuratomi 2009-05-13 15:10:39 EDT
Note that at the distribution level, we'll need to load all the services (which could be directories for KDE, GNOME, xfce, etc), then when a desktop environment is selected, make the directory for the desktop environment to be searched first.  Otherwise, if a user has a service installed that can satisfy a call to the bus but its the one written for a different desktop environment than they're running, they'll get a failure instead of that service.
Comment 15 Kevin Kofler 2009-05-13 16:42:30 EDT
It's the job of comps to drag in the default packages for each environment, not dependencies. Otherwise we end up with packages requiring KDE, GNOME and XFCE components at the same time.
Comment 16 Toshio Ernie Kuratomi 2009-05-13 17:35:35 EDT
well.. let's say that you're running kde.  But you just like to run a different irc client.  That irc client uses the org.freedesktop.Notifications service.  KDE doesn't provide a server for that; it uses the org.kde.knotify service for its apps.  So you install this alternate irc client and it pulls in a package for org.freedesktop.Notifications.  This happens to be xfce4-notifyd (see the current ml discussions).  So the problem is that if you only register the KDE services for your desktop, the notification service won't be found.

You have to be able to find all the services that can be launched on the system but make the search order changable so that you look for a specific one for your desktop environment first.
Comment 17 Matthias Clasen 2009-05-13 20:50:59 EDT
Nah, kde should just support org.freedesktop.Notifications. 
Problem solved, without any complicated overloaded searchpath schemes.
Comment 18 Kevin Kofler 2009-05-13 20:55:28 EDT
Well, then we'd have 3 notification daemons, how to ensure the right one gets activated? Well, I guess in that case the notification daemon can just run on desktop startup and stay there, bypassing the need for D-Bus activation entirely, but that doesn't solve the problem for those services like PolicyKit which do need D-Bus activation to work properly.
Comment 19 Matthias Clasen 2009-05-13 21:07:36 EDT
FWIW, PolicyKit 1.0 is moving away from autostarting the agent, and having it explicitly started by the session and registered with the service.
Comment 20 Toshio Ernie Kuratomi 2009-05-14 00:04:31 EDT
So... KDE needs to write a daemon so that a gnome or xfce app can display notifications?  Somehow that doesn't make sense to me.
Comment 21 Matthias Clasen 2009-05-14 10:00:30 EDT
org.freedesktop.Notifications is a desktop-neutral api for notifications that can have desktop-specific implementations. if kde doesn't implement it, then apps which use that api for notifications won't show them when running under kde. 
Seems entirely logical to me...
Comment 22 Matthias Clasen 2009-05-14 10:02:26 EDT
One way to 'implement' that api would be to add a service file for the xfce or gnome implementation to the dbus service dir thats used in kde sessions, of course.
Comment 23 Colin Walters 2009-05-14 10:18:42 EDT
This bug is definitely a prime example of the terrifying mess that happens when we try to make lower levels of the software stack pluggable, and to express that as a dependency graph.

Anyways.  I see three categories for the cases here:

== MUST NOT BREAK ==

1) An install of the 'GNOME Desktop Envionment' comps group, and the LiveCD
2) Ditto for KDE/XFCE

== Ideally would work, if we can ==

1) Running KDE, install xchat which has a plugin which uses org.freedesktop.Notifications

== Don't really care ==

1) You're starting from a server or minimal image, then "yum install xchat"
2) A GNOME install, you decide to "yum groupinstall XFCE" too
Comment 24 Colin Walters 2009-05-14 10:22:23 EDT
My concrete suggestion here is:

* notification-daemon, due to its status as "reference/de-facto" implementation, lives in /usr/share/dbus-1/services/org.freedesktop.Notifications
* We implement the "service prefix" idea for dbus
* XFCE puts xfce4-notifyd in /usr/share/dbus-1/services/XFCE
Comment 25 Colin Walters 2009-05-14 10:55:17 EDT
Matthias, I'm uncomfortable with relying on KDE to handle this.  Really it's XFCE that introduced this mess, and expanding the scope of the conflict from GNOME/XFCE to include KDE means even more complexity.
Comment 26 Rex Dieter 2009-05-14 11:24:35 EDT
If it matters, KDE has interest in supporting a standard Notifications, providing a few details get worked out, for example,
http://lists.freedesktop.org/archives/xdg/2009-April/010315.html

(but that's a bit offtopic for *this* bug/issue)
Comment 27 Bug Zapper 2009-06-09 07:14:31 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 28 Rex Dieter 2009-08-27 08:49:30 EDT
*** Bug 519654 has been marked as a duplicate of this bug. ***
Comment 29 Bug Zapper 2010-04-27 08:55:39 EDT
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 30 Christoph Wickert 2010-04-27 09:12:38 EDT
Raising version to Rawhide to avoid bugzappers closing this bug.
Comment 31 Bug Zapper 2010-07-30 06:36:10 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 32 Hedayat Vatankhah 2011-10-20 03:10:51 EDT
The bug is still there and really annoying. I don't want to have KDE packagekit handler to be started in Gnome when I click a package... :((
Comment 33 Yaakov Selkowitz 2013-01-14 01:07:38 EST
WRT org.freedesktop.Notifications, most DEs provide their own service provider ("n-d") which is meant to best fit with the DE, e.g. (some of these may not be in Fedora):

* GNOME Shell (builtin)
* GNOME fallback (notification-daemon)
* KDE (builtin)
* MATE (mate-notification-daemon)
* Razor (qtnotifydaemon)
* Unity (notify-osd)
* XFCE (xfce4-notifyd)
* Awesome (builtin)
* E17 (builtin)

The only way to currently have multiple DEs installed and always get the "right" n-d for each desktop is for EVERY n-d to meet *all* the following criteria:

1) No n-d should provide a D-Bus service activation (.service) file.

GNOME already encountered this problem with GNOME Shell (builtin) vs. GNOME fallback (notification-daemon):

http://git.gnome.org/browse/notification-daemon/commit/?id=1ad20d2

The same logic holds true for any others; if any standalone n-d provides a .service file, it is liable to cause a race condition with any other provider (standalone or builtin).

Those packages that currently provide a .service file should have those removed during %install.

2) Each DE SM must launch its n-d at login.

GNOME 3.x does this already via gnome-session.  The easiest way to accomplish this with the other standalone n-d's is to add a /etc/xdg/autostart/*.desktop file with the appropriate OnlyShowIn field, as listed here:

http://standards.freedesktop.org/menu-spec/latest/apb.html

3) The n-d must remain running for the entire session.

Some n-d's exit after a certain idle time, relying on the D-Bus service activation to be restarted when needed again.  As that can't be relied upon in this case, the code must be patched to not do so.  Affected packages are notification-daemon (<= 0.7.0, patch mentioned above), mate-notification-daemon, and xfce4-notifyd, patches for which are available here:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/mate-notification-daemon;a=blob;f=1.4.0-no-exit-on-idle.patch;h=4264529
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/xfce4-notifyd;a=blob;f=0.2.2-no-idle-shutdown.patch;h=56f8954

The same logic and criteria should apply for any other D-Bus service for which multiple DEs ship their own provider.
Comment 34 Fedora Admin XMLRPC Client 2013-02-14 16:05:49 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 35 Fedora Admin XMLRPC Client 2013-02-22 10:07:07 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 36 Rex Dieter 2013-10-08 14:56:36 EDT
*** Bug 1016828 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.