We are going to land polkit 1.0 in F12 soon. This is going to require changes to polkit using applications. Thankfully, mostly simplifications. See http://fedoraproject.org/wiki/Features/PolicyKitOne
Is there any actual PolicyKit-using code in kpackagekit 0.4.x at all? AFAICT it's all handled within PackageKit (or maybe PackageKit-qt) now, a case-insensitive search for "policykit" turns up nothing, neither does "polkit".
From the upstream devs, via IRC well kpackagekit does not (yet) use polkit, but packagekit-qt does, and it does the old way (ie not using polkit-qt) we were planning to make packagekit-qt use it, but as pk1.0 is comming i decided to worry about the polkit-qt por
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
Any update on this ?
So the news is that KPackageKit itself doesn't contain any PolicyKit-using code at all. That said, PackageKit-qt does. Upstream is working on porting that.
The current PackageKit-qt code can be viewed here: http://cgit.freedesktop.org/packagekit/tree/lib/packagekit-qt/src As you can see, PolicyKit support is commented out. :-(
(In reply to comment #6) > As you can see, PolicyKit support is commented out. :-( Right, all the PolicyKit stuff is now done in the daemon, so the proper fix would be to just remove this commented out code IMO.
So PackageKit-qt doesn't need any PolicyKit code anymore? Should we just close this as NOTABUG then?
You want to make sure that you make your mechanism calls async, since they may block in PolicyKit while an auth dialog is shown. But maybe you already do everything async, anyway ?
(In reply to comment #9) > You want to make sure that you make your mechanism calls async, since they may > block in PolicyKit while an auth dialog is shown. But maybe you already do > everything async, anyway ? This is my concern too.
I'll ping upstream and see where we stand on this. -- Steven M. Parrish - KDE Triage Master - PackageKit Triager Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
> Right, all the PolicyKit stuff is now done in the daemon, so the proper fix > would be to just remove this commented out code IMO. Unfortunately, it doesn't seem to be that simple, see Bug 512925.
What is the status of this ? My repoquery -q --whatrequires "libpolkit.so.2()(64bit)" Doesn't list any PackageKit packages anymore, so it seems we are good ? Does PackageKit-qt actually work with polkit, or are there still issues that we need to sort out ?
Well, there's no KDE version of an authentication agent for polkit1 (yet)... so any kde applications using PolicyKit1 will not work unless the gnome authenitcation agent is running in the session. The PackageKit-qt bindings do not need to check anything with PolicyKit anymore (all done in the engine with PolicyKit1) and so should be good to go.
Running the gnome authentication agent is not enough to authenticate in kpackagekit in KDE 4.3.0 (rawhide), see bug[1]. So it seems KDE needs it's own autentication agent in this case? Martin Bug 1: https://bugzilla.redhat.com/show_bug.cgi?id=509136
Yes, Gnome Authentication Agent is not enough for KPackageKit. The question is why it's not enough, why it's not called as from comments above all PK related code is in PackageKit.
This should be fixed by the current PackageKit and kpackagekit builds in Rawhide.