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


<include>/etc/dbus-1/session.conf</include>
<servicedir>/usr/share/dbus-1/services/GNOME</servicedir>

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.

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...

> 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.

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,
http://lists.freedesktop.org/archives/xdg/2009-April/010315.html

(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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

*** 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: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

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):

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.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

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:

https://github.com/cygwinports/mate-notification-daemon/blob/master/1.14.0-no-exit-on-idle.patch
https://github.com/cygwinports/xfce4-notifyd/blob/master/0.2.2-no-idle-shutdown.patch

*** Bug 1499743 has been marked as a duplicate of this bug. ***

Problem is getting a dialog stating:

Error - XFCE PolicyKit Agent

when I connect via VNC to my Xfce system.

Things seem to work, but how would I know?

=======================

System is running Fedora-Xfce-armhfp-29_Beta-1.2-sda

Note I have not tried vnc to Xfce for any prior version of Fedora.

Connecting locally, I have no problem.  No PolicyKit error

I install tiger-vncserver, and change target to multi-user.

I do a bunch of steps to get Xfce working with vncserver.  I change the user/.vnc/xstart to end with:

# exec /etc/X11/xinit/xinitrc
exec  /bin/sh /etc/xdg/xfce4/xinitrc
xrdb $HOME/.Xresources
startxfce4 &

Note that currently, the is no .Xresources file.

When I connect to the user over vnc, I get my Xfce session with the XFCE - PolicyKit Agent error.  This happens everytime I restart the vncserver service (or reboot the system).

It MAY be that I do not have the right invocation magic for Xfce over vnc.  I have not been able to find any good information on this.  I suspect at least I need to add a GEOMETRY statement.

So either this is an Xfce invocation error or somewhere else in the system.  Thus I have posted this problem to this old bug which came up in my PolicyKit Agent search.

This issue affects notifications in XFCE and, in turn, volume control and unmounting USB drives.

Both the plasma-workspace and xfce4-notifyd packages put D-Bus files in /usr/share/dbus-1/services:

org.xfce.xfce4-notifyd.Notifications.service
org.kde.plasma.Notifications.service

and both claim the name "org.freedesktop.Notifications"

If a system has both KDE Plasma and XFCE desktop environments installed then the XFCE notification service does not start automatically.  Anything that would normally trigger a notification within XFCE instead freezes for about a minute.  Examples include:

- Issuing a notification command, eg: notify-send hello
- Adjusting the volume with the mouse wheel hovering over the Pulseaudio Plugin icon
- Attempting to un-mount or eject a drive in Thunar

Manually starting /usr/lib64/xfce4/notifyd/xfce4-notifyd fixes this immediately but is not persistent across reboots.

The journal reveals which D-Bus service is being ignored:

dbus-broker-launch[1786]: Service file '/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service' is not named after the D-Bus name 'org.freedesktop.Notifications'
dbus-broker-launch[1786]: Ignoring duplicate name 'org.freedesktop.Notifications' in service file '/usr/share/dbus-1/services/org.xfce.xfce4-notifyd.Notifications.service'

Editing two lines in /usr/share/dbus-1/services/org.kde.plasma.Notifications.service and rebooting removes the naming conflict and allows notifications to appear correctly in both KDE Plasma and XFCE:

[D-BUS Service]
Name=org.freedesktop.PlasmaNotifications
Exec=/usr/bin/plasma_waitforname org.freedesktop.PlasmaNotifications

Deleting this file entirely also has the same effect, so I'm not sure if this file is needed for anything at all now, since Plasma handles notifications in its own way.