Category: Uncategorized

Anyone interested in PackageKit develpment is invited to join the channel #PackageKit on freenode.
We can answer questions on backends, GUI's or anything else PackageKit related.

The PackageKit source tree needed gtk, libnotify and all sorts of weird gnomey libs to compile, which seemed to upset the non-GNOME people a little. The actual daemon just needs glib, libnm, dbus-glib and policykit so it did seem somewhat non-optimal to me as well. I've split the daemon and GUI parts into two projects:

 git clone git://people.freedesktop.org/~hughsient/PackageKit git clone git://people.freedesktop.org/~hughsient/gnome-packagekit 

Just install gnome-packagekit when you have PackageKit installed – gnome-packagekit uses libpackagekit to do all the heavy lifting, so the GUI bits are actually very simple:

 [hughsie@hughsie-laptop src]$ wc -l *.c *.h    56 pk-application.h   725 pk-application.c   104 pk-application-main.c    60 pk-notify.h   958 pk-notify.c   76 pk-update-icon.c   1979 total 

In the gnome-packagekit project I'll start marking strings translatable, and there's also a yelp file for someone to fill out for me in the future. I might move gnome-packagekit to GNOME svn when things are a bit more stable, so stuff like translations and HIG changes are easy to commit. This means it's really trivial to port an existing applications to use libpackagekit, or to create, for example, kpackagekit.

Okay, quite a major omission on my part, but the PackageKit 'Package' signal previously didn't send the version or architecture of the queried package. It does now.

I've also merged in the start of a conary backend (thanks Ken!) and made the spawn code an order of magnitude faster. There's also quite a bit of interest in making a pacman and emerge backend for PackageKit too.

This morning I've added the RequireRestart signal into PackageKit, and connected it up with the server and client. All code is in git master.

The restart types are system (reboot), session (logout and back in) and application (restart program).
Only the dummy backend supports this for now, although it's trivial to add to the others.

Request for yum help:

Do you know python? Are you familiar with rpm and yum internals? if so please email me – the yum backend needs some serious love. I've got a few people helping with PackageKit the moment; Tom Parker is rocking with the libapt-pkg backend and skvidal and Luke Macken are helping with the yum backend but I need more people to write new backend code.

Request for backend writers:

Want to join the fun? The core code and API are ready, any there is even a README for you to follow. I would like to see urpmi and conary backends added next week if possible. All it takes is someone very familiar with the packaging system and a few hours of time. If you supply me with scripts that adhere to the common helper standard then I'll even wire up PackageKit for you.

Thanks.

PackageKit has an application called pk-update-icon that is run once per session automatically. It is a lightweight binary that just calls into PackageKit and watches for status changes. It initiates the Refresh (non-forced) and GetUpdates after login and periodically checks for updates every couple of hours. This isn't configurable, but it would be trivial to hook up to gconf.

It has two status area icons, one for PackageKit current status and one for updates. Hold the pitchforks.

The PackageKit status icon only appears when a job is in progress, for instance a cog icon appears when doing an rpm install. It disappears when PackageKit is shutdown, which is currently after 60 seconds idle. It's basically a way of seeing what PackageKit is currently doing.

The update icon only appears when there are updates available, and additionally a libnotify window appears if there are critical updates available. Below is the dummy backend displaying the data, as yum doesn't seem to know if an update is security sensitive or normal. Ideas welcome on how to fix this.

Code is in git. My English spelling and grammar are crap (as usual), and nothing is localized, but that can be fixed later. Or alternatively, I accept patches.

Two new features coded today:

For PackageKit we don't want to be refreshing caches or checking for updates when there is no network connection. Does anyone have a short guide on how to monitor and query the connected state of nm (session or system), just like evolution does? Any nm guys want to write me a quick patch or jot down some quick code? Cheers.

EDIT: Done, thanks guys.

git clone git://people.freedesktop.org/~hughsient/PackageKit

Patches accepted. Thanks.

edit: Now git clone git://anongit.freedesktop.org/git/packagekit

Work on PackageKit continues. The new manager application has lots of human-unfriendly options now, but allows people to experiment with all the features and more importantly allow people to look at the code and work out how to port their app to support PackageKit.

There's quite a few API additions now also, with different search modes and also error codes and descriptions. The API will grow some more soon also, to get the extended description of a package along with a URL and any further information not contained in the summary. Then I think it's complete.

I've now split the dummy and yum backends, so in theory the yum backend could be soon complete. I'm adding the yum scripts as skvidal is kindly writing them, and hopefully everything should soon be in place for the other backends.

So, answering some FAQ's (I've had hundreds of emails about PK in the last 2 weeks):

• Hopefully gnome-app-install will use the PackageKit API soon. Sebastian Heinlein is already volunteering to do the porting.
• A conary backend can be created really soon. I just want to finish a little more the yum backend and move some of the shared spawn code so the minimum code is duplicated. I'll also need to add a shitload of documentation.
• A trivial apt backend will be created by me doing screenscraping of apt-get. A much better backend can be created by someone who knows C++ and is familiar with libapt.
• You don't have to have a backend that supports percentage updates. If you don't know the progress, just emit NoPercentageUpdates and then the UI should just do the right thing and spin.
• Backends don't have to support all options of all methods. Just set an error and return false if not implemented.
• Error codes have to be standardized so they can be localized. The error detail field can just be the untranslatable output. If you are creating a backend and you need another error enum, yell, and we can add it to the supported list.
• Upgrading, installing or removing packages has to be silent. The user cannot be prompted for questions “set applet setuid?” as these will not be handled in PackageKit. This is not an issue for rpm but will be for apt. The backend should do the right thing, as these messages mean very little the the average user and cannot be translated.
• PackageKit does not replace up2date. PackageKit is a way for users to interact with the packaging system, not for an administrator to install software on remote machines.
• PackageKit is not yet another system daemon. It quits when not doing anything, and only starts when something wants information or a task completed.
• PackageKit does not do dependency resolution. This problem has already been solved by the backend systems and I don't really want to re-invent the wheel.
• PackageKit does not have the fine-grained API to do everything. For instance, synaptic should still use libapt as can do much more than can be provided by PK.
• PackageKit is not a replacement to red carpet. Red carpet was really great and years ahead of it's time, but tried to do everything package related on the system, and moved onto the enterprise centralized management model. Although cool, this latter point made things too political IMO.
• PackageKit is not vapourware. I'm just waiting for fd.o git space and if that doesn't come about soon I'll just dump the code on code.google.com for a temporary solution. Then I'll start taking patches. All the applications work, they are not mockups. There are F8 rpm's in my repo also if you want a sneak peak.
• PackageKit is fast. It takes about 1 second to search for installed and available packages with “power” in the description – no blocking of the UI happens at all as it's all async. All the applications start instantly with no root password needed at startup.
• PackageKit is designed from the ground up to work with fast user switching and logging in and out of sessions during upgrades. You can start a system upgrade, log out, log in as another user, and be notified when the upgrade is complete, all without risking your rpmdb.
• PackageKit does not stop you using the low level tools yourself. You can use rpm and yum or dpkg and apt when PK is inactive (99.999% of the time) when you really need some command line love. No more fighting over yum, yum-updatesd, pup and pirut.
• PackageKit is not sponsored by anyone. Whilst interning at RedHat I spent a few days on the API and some UI designs, but all the coding is done in my free time.

So, good things.

PackageKit now has an update applet and application installer. This demo-application will win no awards for UI design, but the idea is to show how easy it is to make an async frontend for the provided dbus interface.

Also, the trivial update icon runs once per active session, and communicates with a single system instance of PackageKit. When the service is needed it is activated using dbus system activation, and when it's doing nothing the system daemon quits.

This means we can queue multi-session updates and installs. For instance I can start an update in my user session, switch to my girlfriends session, and then search for pidgin, and queue the install. The install will start when my update has completed. Maybe a more useful situation would be for the gdm login to start doing the daily updates before a user even logs in. OpenOffice could install language packs in the background as soon as you start typing in a new language. Lots of fun stuff.

Of course very little of this actually works properly. The dummy backend does mostly the right thing, and the apt and yum backends can search, but I still need to do the rest of the actions. The PolicyKit bit is still to be done.

So, good things.