[ Tuesday, 30 September 2008, patpi ]
PackageKit is a system designed to make installing and updating software on your computer easier. The primary design goal is to unify all the software graphical tools used in different distributions. KPackageKit is the KDE interface for PackageKit. Today we talk with Packagekit-Qt and KpackageKit developers about new emerging possibilities in process of managing software on your desktop.
Today we talk with Adrien Bustany and Daniel Nicoletti, PackageKit-Qt and KpackageKit developers:
Adrien Bustany: PackageKit is an abstraction layer above several package managers (yum, apt-get, conary…). It hence defines a standard interface to interact with the package manager on any system, and allows deeper integration with the desktop. PackageKit is a daemon started on demand via dbus, all the commands to the daemon are also passed via dbus, which makes it platform independent. The actions are controlled by PolicyKit, which allows to define precisely the rights of each user. Historically, PackageKit was shipped with a glib based abstraction lib, and a GTK+ frontend.
PackageKit-Qt is the qt equivalent of the glib abstraction lib. It talks with the daemon via dbus, and exposes convenient method to the programmer to control PackageKit (without having to deal with the dbus internals). Among other things, this means that a change in the dbus API will not necessarily break a software using PackageKit-Qt, as the changes will be taken care of by the lib. PackageKit-Qt is a pure Qt lib and does not depend on KDE classes. KPackageKit is a frontend using PackageKit-Qt, but I’ll let Daniel talk about that.
Daniel Nicoletti: Well then to describe better what KPackageKit is I can say that this is like a puzzle, we have three kcm (system setting) modules one for managing search, install, remove another for managing updates and refreshing cache and the last one to manage the settings and proxy. Plus to that we have a KDED module that keep track of the state of packagekitd, if it notices that we have more transactions it call KPackageKit executable, the KDED also do the refresh cache stuff. And the last one KPackageKit executable, it hold an icon to show the list of transactions, show popups about new updates, a need to restart.. and will have all the kcm modules (listed above) to manage installation of packages files (as system setting can’t handle arguments)
Add and remove software in System Settings:
So KpackageKit is a frontend for libpackgekit Freedesktop.org specification, what does it mean in practise? Will this Freedesktop specification change the current state of the process of managing software on Unix-like computer systems?
Adrien: KPackageKit is a frontend to PackageKit, not libpackagekit (see paragraph above). Libpackagekit uses the glib signal system while PackageKit-Qt is pure Qt.
Here’s a simple schema describing how it works :
PackageKit daemon --- DBus ---> libpackagekit/PackageKit-Qt/other --- linked with ---> Gnome-PackageKit / KPackageKit
PackageKit definitely opens new possibilities with package management, among them automatic installation of drivers, cliparts, applications to handle a given mimetype… Some work is going on, but the lack of standards is sometimes slowing it down.
Daniel: Actually KPackageKit is just the UI, the lib PackageKit-Qt is really the one who uses the Freedesktop specification and talks with DBus. Well PackageKit is not and will never be intended to substitute the actual process of managing software, you can still use aptitude, yum, rpm and dpkg. The idea is just do a mapping of all the common tasks needed by an end user and give him a easy way to do it.
PackageKit is also different from others tools. It does not slow down your start up, in the KDE (and only in it) version you only lose 1~2mb of RAM as this is a KDED module and does not have to load a complete program. As Adrien said PackageKit has a daemon (packagekitd) that is DBus activated this means that packagekitd will only run when needed. On Gnome front end there is a gpk-smart-icon program that is running and consuming resources (6~8mb) all the time. On KDE there’s only a module in KDED (1~2mb) running all the time and if it detects PackageKit transactions or see that it need to refresh the cache it calls KpackageKit that will only run when needed. If kpackagekit (I’m referring to an executable, cause all things on system settings are just kpackagekit modules) detects that there’s nothing more to do it quits and frees you memory, and doesn’t slow your KDE startup.
And what is the current state of software managers in Linux/Unix world? What is good enough and what should be better in your opinion?
Adrien: I only know yum, and a bit of apt-get… Both fulfil my needs, I don’t think there’s a lot of work to do on package managers, although I’d really like to have delta updates with yum (there’s presto, but it’s alas not widely used).
Daniel: Well, I use Debian in my humble opinion aptitude is just awesome the only thing I miss in it is the possibility to do dpkg tasks like installing a package from a .deb file and also resolve it’s dependencies, and I miss apt-setup.
What are the main goals for PackageKit-Qt and KpackageKit at the moment?
Daniel: Well PackageKit-Qt can be better explained by Adrien since it’s mainly developed by him, but I think the lib is getting in shape and this will enable a lot of Qt/KDE software’s to use it. KPackageKit is also almost in good shape, but the main goal of it is the reason why I joined the team, last year (December) I was finishing my graduation with a program called Doka (a download accelerator for KDE), the Kget team invited me to join the team (sorry dudes), but I got an idea what should be different in Linux to make it more user friendly than Windows, and voilà why not right click an icon on Kickoff and have an option telling “uninstall this app”, I though this would be awesome, so I went on #kde-devel to see what was the KPackage state in KDE4 and someone (I think pinotree) told me about packagekit, and I started to hack ( I spent 3 months just trying to get it running , but that was because apt backend wasn’t in good shape), then i met Adrien that had developed QPackageKit but at that moment it was.. how can i say.. Waiting for contributors
Adrien: The main goals of PackageKit-Qt are :
- Being useful for KPackageKit, but I’m also open to any other ideas if someone else is using it
- Being up to date with PackageKit’s DBus API
KpackageKit in action:
What is the current state of PackageKit-Qt and KpackageKit? Where is the project now and what is the roadmap for future?
Adrien: I’ll answer again only for PackageKit-Qt :
The API follows PackageKit’s API, so its stability is the same as PackageKit’s (which means it regularly changes). I believe that the lib is usable, since Daniel managed to make something out of it I don’t really have any roadmap for the lib, it’s mostly “binding” work, there’s almost no designing work involved.
Daniel: Both have a almost release state, PackageKit-Qt is in better shape. Now the project is hosted in a private git at packagekit.org, and available to the user at kde-apps.org.
The roadmap I think will be getting into KDE svn (I would love to see it using git), and Fedora 10 maybe will use it for the KDE desktop. We also need to do a better integration with KDE to get proxy, network state, power management (to not automatically install updates if the computer is running on battery), and track turn off calls. Actually only turn off is needed by PackageKit since you can login and logout without stopping any transaction
Software management in Linux/Unix world can be hard to learn for newcomers – everyone can realise it on any Linux/Unix forum/mailinglist/etc. However, in my opinion, software management is one of the fundamental advantages of FLOSS software. By streamlining and unifying software management between distributions you can underline FLOSS strengths. However to achieve this PackageKit-Qt and KpackageKit have to be usable and discoverable for all type of users. How do you take care of this in your project?
Adrien: A great thing for us would be the inclusion of KPackageKit in KDE 4. We’re now reaching a beta state where the feature set of KPackageKit is more or less equivalent to its GNOME counterpart. Unfortunately, some server issues (I have a freedesktop account but can’t access it) makes the code hard to try. However, the library and the GUI are now packaged for Fedora and Ubuntu in their development flavours, so we hope to get some feedback.
Daniel: Well I think the most normal way of at least removing software is going to Control Panel (similar to Windows), that’s why I created kcm modules so the user can easily find it in System Settings, also the right click to uninstall application can be somehow discoverable.
After I put KPackageKit in shape I’m thinking of creating a sort of KTutorial, yes a new project it’s at mind state right now, but I want to create a nice way for a newbie user, so we can explain to him where he will find the programs that he needs.
Searching and Update Viewer in action:
Interesting ideas. Is anyone helping you with design and user experience or do you design UI on your own?
Adrien: We work as a small team, and generally discuss our issues together. We’ve got no external contributions so far.
Daniel: The design is created in our own but the add and remove delegate is an adapted version of that add widgets to desktop. The updater UI will use it in the future but as it’s a tree I have to do some fixes as the delegate does not resize correctly.
And does someone from KDE Usability team helped you with designing a GUI? I think that they can provide usability feedback and also try making installation and unistallation of applications more ergonomic.
Daniel: No, no one from this team helped us.
Adrien: But we didn’t contact them either. We could benefit from their feedback. Any feedback actually
What the project needs more? Developers, testing and bug hunting, better marketing or anything else?
Adrien: Mostly testers. Bugs in the GUI will often be the cause of bugs in the lib, so it’ll allow me to fix them. Marketing will come through the inclusion in various distributions, so I don’t think there’s a great need for it.
Daniel: Developers would be nice since me and Adrien got very busy sometimes, but we don’t need tons of it the project is really simple. Testing is very very important to us since there are many use cases and the fact that some backend does not support all the stuff, so the testing is very important. The marketing I think will be “easy” as some distributions are adopting it. I would say translations, someone with “oxygen” skills to create animated icons (downloading, installing …) and people to develop backends to more distros. I would suggest slackware Slapt since If I recall correctly is not supported at the moment.
Thank you for this interview.
KpackageKit version 0.1 and QPackageKit 2.0 have just been released at kde-apps.org. and are ready for testing. Any feedback is appreciated. Bugs and wishes about KpackageKit and PackageKit-Qt should be submitted to PackageKit mailing list or directly to the authors.