Bug 474530

Oops, that should be /etc/xdg/autostart/xdg-update-icon.desktop.

Same problem here.

It should be /etc/xdg/autostart/gpk-update-icon.desktop
:)

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.

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.

Disabling the GNOME applet in KDE is special-casing KDE. Overriding it in kpackagekit is the right solution.

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.

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

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?

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

The class of F-10 kde users who've manually removed kpackagekit?  They can also manually re-enable gpk as well...

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.

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.

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?

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.

That works for me.  The whole jist of my idea was to somehow force kpackagekit to get pulled in, and that does it.

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.

Going to bring this up again at the next SIG meeting and see if we can get this solved.

Since plasma is now in kdelibs (kde42), maybe Kevin's idea in comment #16 is more appealing now.

ping?

Yes, it would be nice to have this fixed in F11 if at all possible.

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.

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

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

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.

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.

I wrote this blurb:
https://fedoraproject.org/wiki/Documentation_Desktop_Beat#Software_Updates_.28PackageKit.29

Can't the option of one or the other be configurable someway? Maybe in /etc/sysconfig/packageKit with an option, or using alternatives?