Polkit and KDE: let’s make the point of the situation

Hello folks,

Welcome to a post describing the current and future status of all things PolicyKit, polkit, $%$”, whatever related to policy handling in KDE, for users, developers, packagers and distributors. A must read, let’s say :).

PolicyKit, polkit… what the hell?

Yes, PolicyKit and polkit are two different pieces of software. After reaching version 0.9, PolicyKit has been discontinued, and polkit-1 took its place. polkit-1 is not backwards compatible with PolicyKit, but still it is able to run together with it, even if you probably don’t want to do that. Also the API are completely different, so polkit-qt was no longer sufficient to cover up polkit-1. That’s the reason why polkit-qt-1 was born.

Yet another Qt wrapper: polkit-qt-1

First things first, the main credits for polkit-qt-1 go to the awesome Fedora KDE team, especially to Radek Novacek, Jaroslav Reznik and Lukas Tinkl, who did most of the job, whereas I mainly reviewed and put quite a lot of finishing touches. Now that credits are due, let’s dive into what is polkit-qt-1. It is a wrapper library around polkit-gobject and polkit-agent, which lets developers write easily applications using polkit-1, and even write custom authentication agents.

Compared to polkit-qt, the API is much nicer and the library itself is much more polished: I also changed a lot of things I wanted to change in polkit-qt (especially in the GUI part) but I couldn’t do for the sake of BC. Of course you are NOT encouraged to use this library if you’re developing on the KDE Development Platform >= 4.4: you want to use KAuth instead. But, if your application depends only on Qt or you need to do something strictly related to polkit-1, then polkit-qt-1 is your first choice.

Then what about polkit-qt?

Polkit-qt will experience one last release (0.9.3), on which trunk already depends on. This release is critical for it to work well with KDE 4.4 and Qt 4.6. I sincerely hope this will be the very last release of polkit-qt, since the only reason why I will want to do another one is for fixing a critical bug.

Ok. In all of this mess, I didn’t really get the point of what’s happening with polkit or PolicyKit in KDE 4.4

Fairly reasonable. Let’s try to get things explained better. There will be lots of changes from KDE 4.4 to KDE 4.5. KDE 4.4 will still use PolicyKit 0.9 and polkit-qt as the default supported authorization framework. This is because polkit-1 has not yet been released to a stable version, and because we’re not yet in feature parity with the GUI tools PolicyKit 0.9: the authorization manager KCM is not there yet in polkit-1.

Polkit developers decided not to provide a similar tool in GNOME. I feel this is a strong regression, as a lot of users appreciated the authorization manager and used it to solve some policy related problems, and it’s a tool of unvaluable help for system administrators. For these reasons, KDE will surely provide in the near future a similar tool for polkit-1.

Just like it happened with KDE 4.2, the KDE tools for polkit-1 will be released separately. They now lie in extragear/base/polkit-kde-1. Only the authorization agent is in (which is the authentication dialog), the KCM will be developed later. I will do a release shortly (in a pair of days) together with polkit-qt and polkit-qt-1, and I will post a small entry on my blog when I’ll do.

KAuth has a working backend for polkit-1 based on polkit-qt-1: however, the default backend is still the one based on polkit-qt. To use KAuth with polkit-1, simply compile kdelibs with -DKAUTH_BACKEND=PolkitQt-1, and that will do.

And for developers? Well, if you used KAuth, don’t you worry. You don’t have to port a single line of code. Just recompile kdelibs as explained above, recompile your application from scratch, and watch it run on the top of polkit-1. Sooo amazing.

And what about KDE 4.5?

In 4.5 the following things will happen:

• polkit-kde-1 will be moved to kdebase/workspace
• PolicyKit-kde in kdebase/workspace might be removed and put in extragear, where it will enter maintenance mode.
• polkit-qt might be removed from kdesupport and put somewhere on gitorious
• In KDElibs, KAuth will default to polkit-1 for its backend

This is because by the time 4.5 will be released, probably PolicyKit 0.9 will be completely deprecated, and polkit-1 be absolutely ready for prime time.

The “might” points have to be discussed with the whole community, and they will probably strongly depend on the situation of PolicyKit at the time when the decision will be due.

Awesome. Now it’s all clear: just tell me what I need and where to grab it

KDE 4.4 trunk opt-depends (since a pair of hours, actually) on polkit-qt 0.9.3 and polkit-qt-1 0.95.1, both of which have not yet been released, but if you compile kdesupport from trunk you can simply do a fresh checkout. They will get official releases in a pair of days, just to let some hours pass. polkit-kde-1’s first release will happen together with the two libraries, but if you’re extremely impatient you can check it out in extragear/base/polkit-kde-1.

Good. But since we’ve reached the end of the post, what about giving a small advice on which polkit/PolicyKit should I use?

Uhm, now you’re becoming pretentious… ok -.-. Look, if I were a distributor, and all the major tools (NM, HAL, whatever) started requiring polkit-1 and KDE would be the only thing using PolicyKit, I’d go for polkit-1 to avoid having 2 system that do the very same thing overlapping. But, if that was not the case, I’d probably stay with PolicyKit 0.9.

If you were wondering, I have both (PolicyKit and polkit-1) installed, as you might have imagined, but I’m still using the first. I will probably move to polkit-1 soon, though, since it’s the future and I don’t like living stable 🙂

I hope you enjoyed the post, which was hopefully explainatory and complete. For any questions, drop a line in the comment box.

~ by Dario on 22 December, 2009.