Bug 474530 - gpk-update-icon runs in KDE4 session alongside kpackagekit-smart-icon
gpk-update-icon runs in KDE4 session alongside kpackagekit-smart-icon
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: gnome-packagekit (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-04 05:43 EST by Peter TB Brett
Modified: 2009-04-23 07:47 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-03-17 14:05:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter TB Brett 2008-12-04 05:43:00 EST
Description of problem: When running a KDE4 session, installing updates with packagekit causes both the kpackagekit *and* gnome-packagekit icons to appear in the system tray.

Version-Release number of selected component (if applicable):0.3.9-8-fc10

How reproducible: Always.

Steps to Reproduce:
1. Log in to KDE session
2. Wait for prompt to install updates.
3. Agree to install updates and enter root password.
  
Actual results: gnome-packagekit is run to install updates, and both GNOME and KDE packagekit icons appear in system tray during install process.

Expected results: kpackagekit is run to install updates. Only the KDE packagekit icon appears in system tray during install process.

Additional info: xdg-update-icon is launched by desktop files in /etc/xdg-update-icon.desktop.
Comment 1 Peter TB Brett 2008-12-04 05:45:22 EST
Oops, that should be /etc/xdg/autostart/xdg-update-icon.desktop.
Comment 2 MartinG 2008-12-04 05:49:32 EST
Same problem here.

It should be /etc/xdg/autostart/gpk-update-icon.desktop
:)
Comment 3 Kevin Kofler 2008-12-04 06:12:32 EST
Well, we were planning to implement a solution in kpackagekit which disables the gnome-packagekit icon in KDE only if kpackagekit is actually installed. Because there's nothing which drags it in on upgrades from Fedora 9. And some localized KDE spins are still using gnome-packagekit because kpackagekit didn't get translations in time for the release. Reassigning so this actually gets implemented.
Comment 4 Peter TB Brett 2008-12-04 07:17:47 EST
This seems like the wrong solution. Are you going to add more special cases for each and every other desktop environment that comes along with its own PackageKit frontend? It would make more sense to me for session types to opt-in to using the GNOME applet rather than having to opt-out.
Comment 5 Kevin Kofler 2008-12-04 07:23:55 EST
Disabling the GNOME applet in KDE is special-casing KDE. Overriding it in kpackagekit is the right solution.
Comment 6 Richard Hughes 2008-12-04 07:33:23 EST
Bear in mind the patch gnome-packagekit-enable-kde.patch that shows some menu items in KDE. I guess we need to nuke that now.
Comment 7 Kevin Kofler 2008-12-04 07:41:22 EST
Well, if you do that, you'll fix this problem, but you'll break things for users who still don't have kpackagekit for whatever reason (such as upgrading from F9). :-( That's why I'm saying this has to be solved in kpackagekit (and we already discussed this within KDE/kpackagekit maintainers, just didn't implement it yet).
Comment 8 Rex Dieter 2008-12-04 08:49:28 EST
The solution as Kevin mentioned in comment #3 fails due to currently unknown bugs in kde's autostart code.

Imo, the best way forward atm is for gnome-packagekit to drop the enable-kde patch for F-10+.  F-9 users will have to fend for themselves (at least until we can fix the aforementioned kde autostart issues).

Comments?
Comment 9 Kevin Kofler 2008-12-04 08:53:50 EST
Well, I think we should really fix the bug in kdelibs, but if you think the quick hack is the best way forward, so be it. It'll mean a class of users will end up with no working updater though. :-(
Comment 10 Rex Dieter 2008-12-04 08:58:58 EST
The class of F-10 kde users who've manually removed kpackagekit?  They can also manually re-enable gpk as well...
Comment 11 Rex Dieter 2008-12-04 09:00:01 EST
In the meantime, I'll work on documenting (and bugzilla'ing) the issue wrt kde's autostart overrides, in the hopes that it's implementation may well win out in the end.
Comment 12 Kevin Kofler 2008-12-04 09:04:51 EST
The class of users who upgraded from F9 and so never had kpackagekit installed in the first place. And also the class of users who installed from Sebastian's F10 KDE German spin which uses gnome-packagekit because kpackagekit wasn't translated (and by the way, we still don't have a translated version in the updates). And maybe other localized spins too, I don't know what their maintainers decided to use.
Comment 13 Steven M. Parrish 2008-12-04 10:09:29 EST
IMHO we should kill the gnome-packagekit-enable-kde.patch  and then and make sure during the same update push that we push a version of kdelibs which requires kpackagekit.  That will insure that as gpk is disabled kpackagekit is installed.

Opinions?
Comment 14 Rex Dieter 2008-12-04 10:21:06 EST
Adding a hard-coded dep to kdelibs is bad for a multitude of reasons.

Maybe kde-settings, a subpkg akin to -pulseaudio?
kde-settings-packagekit that contains:
Requires: kpackagekit
Obsoletes: kde-settings < (last VR without -packagekit)
Requires: kde-settings = %{vesion}-%{release}

This should handle the upgrade issues, and pull in kpackagekit for everyone, while leaving the ability to remove it if desired.
Comment 15 Steven M. Parrish 2008-12-04 10:27:56 EST
That works for me.  The whole jist of my idea was to somehow force kpackagekit to get pulled in, and that does it.
Comment 16 Kevin Kofler 2008-12-04 10:32:14 EST
That should work (assuming the "vesion" typo gets fixed ;-) ). It'll drag in kpackagekit for some non-KDE users (with only KDE apps, not the KDE workspace), but I can't think of a solution which doesn't: the technically correct place to put the dependency in would be kdebase-workspace, but that is dragged in by some application modules due to libplasma, so it wouldn't help all that much.
Comment 17 Steven M. Parrish 2009-01-10 09:56:35 EST
Going to bring this up again at the next SIG meeting and see if we can get this solved.
Comment 18 Rex Dieter 2009-01-16 15:07:06 EST
Since plasma is now in kdelibs (kde42), maybe Kevin's idea in comment #16 is more appealing now.
Comment 19 Steven M. Parrish 2009-03-16 22:09:16 EDT
ping?
Comment 20 Peter TB Brett 2009-03-17 03:21:13 EDT
Yes, it would be nice to have this fixed in F11 if at all possible.
Comment 21 Kevin Kofler 2009-03-17 03:40:53 EDT
The problem is that we still don't have a working solution which doesn't break things for one or the other group of users. (The proposed solution described in comment #3 is not working due to how kdelibs looks up autostart services.)

I can think of only 2 possible solutions:

Solution A:
1. add Requires: kpackagekit to kdebase-workspace
2. drop the enable-kde patch from gnome-packagekit
3. make sure the 2 changes get pushed out together as grouped updates

Advantages of solution A:
* allows fixing the issue even on F9 and F10
* no manual setup needed

Drawbacks of solution A:
* KDE users will not be able to remove PackageKit entirely. I know some users do that, they will not be happy with this solution.
* KDE users can no longer use gnome-packagekit without manual hackery should they wish so.

Solution B:
1. drop the enable-kde patch from gnome-packagekit on F11 and higher only, keep it for F9 and F10
2. document this change in the release notes

Advantages of solution B:
* no bogus dependencies dragging in kpackagekit
* no need to worry about the effects of changes to stable releases

Drawbacks of solution B:
* can't fix the issue on F9 and F10
* needs manual fixup on upgrades to F11 (for those users still using gnome-packagekit in KDE)
* KDE users can no longer use gnome-packagekit without manual hackery should they wish so.
Comment 22 Richard Hughes 2009-03-17 06:58:28 EDT
(In reply to comment #21)
> Solution B:
> 1. drop the enable-kde patch from gnome-packagekit on F11 and higher only, keep
> it for F9 and F10
> 2. document this change in the release notes
> 
> Advantages of solution B:
> * no bogus dependencies dragging in kpackagekit
> * no need to worry about the effects of changes to stable releases

This is best for me, and I think the cleanest solution.

Richard.
Comment 23 Richard Hughes 2009-03-17 07:02:47 EDT
(In reply to comment #21)
> Solution B:
> 1. drop the enable-kde patch from gnome-packagekit on F11 and higher only, keep
> it for F9 and F10
> 2. document this change in the release notes
> 
> Advantages of solution B:
> * no bogus dependencies dragging in kpackagekit
> * no need to worry about the effects of changes to stable releases

This is best for me, and I think the cleanest solution.

Richard.
Comment 24 Kevin Kofler 2009-03-17 12:32:06 EDT
We discussed this in the KDE SIG meeting and opted to go with this "Solution B". So can you please disable the enable-kde patch in gnome-packagekit for F11/devel? (But please keep it applied in F-9 and F-10!) I'll take care of the release notes.
Comment 25 Richard Hughes 2009-03-17 14:05:35 EDT
Kevin, thanks. If you can write a note in the release notes then I think we're good to go for F11. Thanks to all involved.
Comment 27 Martí­n Marqués 2009-04-23 07:47:42 EDT
Can't the option of one or the other be configurable someway? Maybe in /etc/sysconfig/packageKit with an option, or using alternatives?

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