Red Hat Bugzilla – Bug 484945
D-Bus activation needs a way to prefer one service over the other depending on the running desktop environment
Last modified: 2016-11-15 10:58:36 EST
Description of problem:
Currently, if 2 programs provide the same service, D-Bus activation just picks an arbitrary one:
/* 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):
(but this has been there ever since D-Bus activation exists and is not fixed in the D-Bus trunk yet either)
Steps to Reproduce:
1. Install PolicyKit-kde on a system with PolicyKit-gnome already installed.
2. Start KDE.
3. Start KPackageKit.
We'd happily do the required changes in PolicyKit-kde, but we need D-Bus fixed. Or can you suggest a reliable workaround?
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.
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.)
I was thinking of subdirectories, i.e. /usr/share/dbus-1/services/GNOME/
Can't you already do that, by having each desktop environment use its own dbus session.conf file, with an additional <servicedir> directive ?
I guess it would just be
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.
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.
Yes, you are right, currently the bus is started from
According to the dbus-daemon man page the last specified servicedir is scanned first. Gotta love that...
> Yes, you are right, currently the bus is started from
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`
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.
Filed upstream, feel free to continue there: https://bugs.freedesktop.org/show_bug.cgi?id=20099
Killing the bus is a bad idea because the reason it runs early is to let "early things" use it.
Yeah, killing the bus is out of the question
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?
*** Bug 498867 has been marked as a duplicate of this bug. ***
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.
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.
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.
Nah, kde should just support org.freedesktop.Notifications.
Problem solved, without any complicated overloaded searchpath schemes.
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.
FWIW, PolicyKit 1.0 is moving away from autostarting the agent, and having it explicitly started by the session and registered with the service.
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.
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...
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.
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
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
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.
If it matters, KDE has interest in supporting a standard Notifications, providing a few details get worked out, for example,
(but that's a bit offtopic for *this* bug/issue)
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:
*** Bug 519654 has been marked as a duplicate of this bug. ***
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:
Raising version to Rawhide to avoid bugzappers closing this bug.
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:
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... :((
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):
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:
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:
The same logic and criteria should apply for any other D-Bus service for which multiple DEs ship their own provider.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
*** Bug 1016828 has been marked as a duplicate of this bug. ***
Current patches for comment 33: