Technical Blog of Richard Hughes

PackageKit now locks the org.freedesktop.Hal.Device.SystemPowerManagement interface on HAL when a backend task is marked as non-interruptable. This basically means that if you start a system upgrade and then click hibernate then it will allow it during the download phase but deny it during the actual install phase.

This also works with multiuser fast-user-switch environments, where Tom wants to suspend after Alice has started a package update. Hopefully, this means no more nuked rpmdb's or broken apt-caches.

But, as you can see, gnome-power-manager just detects this as a generic failure and can't give the user any decent feedback to why it failed.

What I'm suggesting is for PackageKit to emit a ::Locked signal that gnome-power-manager can detect and automatically inhibit internally. This hardcodes the power manager to the package manager which is probably bad, but does give us a nice UI.

What might be better for PackageKit to emit the ::Locked signal over DBUS, pk-update-icon to catch it and issue a session Inhibit() to gnome-power-manager. This would mean we get a decent error message we can show the user, although introduces another layer of complexity and requires the update icon process to be running to get the messages.

EDIT:

Do any mandriva developers read p.g.o? Does anyone want to write a urpmi backend for PackageKit? Join the mailing list and start asking questions and we'll do our best to help you. Thanks.

4 quick questions:

• Do we let the user do a manual system update on battery power?
• Do we do the automatic security updates on battery power?
• Do we allow long transactions (e.g. update kernel) to be scheduled when we are low on battery power?
• Do we make these options configurable in just gconf or in the UI?

I committed a small chunk of code to gnome-packagekit to automatically apply updates if the user has specified this in the preferences tool. If you ask PackageKit to remember the authorization across reboots for updating packages then this becomes a zero-click way of installing updates automatically.

This only happens when the user is idle (using gnome-screensaver) and when the user is online (using NetworkManager) although other code can be compiled in for other stacks.

There are not many release blockers now, so please test and report any bugs to the mailing list. In other news, Adrien Bustany has started QPackageKit, with a C++ wrapper and QT client tools for PackageKit. So, good things.

The transaction viewer application allows the user to see what was done, and when. It also allows the user (power user?) to rollback to previous checkpoints if the backend allows this and the admin has granted permissions.

It's a pretty trivial application. Notice the use of mail-send-receive to denote downloading a package. That makes me feel dirty inside. There's a whole load of icons that need drawing, such as:

• package-install
• package-download
• package-update
• package-remove
• transaction-suceeded
• transaction-failed
• software-update-low (software-update-available and software-update-urgent already exist)

If you want to volunteer for this (or know of suitable icons) then please yell. They have to be Tango style, and available in 22×22 png and svg file formats. Thanks.

I didn't like writing this UI, but to get PackageKit into a couple of distros we need to be able to do a GPG handshake when we install a new repo. I'm questioning whether this is indeed a security measure, but for now I'll run with it.

The following UI will be shown when you try and install an external repo like livna or freshrpms after you've installed the foo-release rpm.

Does this make sense to people? It's designed for users who know what installing a new repository means, rather than new users who are just using the distro supplied repos.

Rob Norwood is the dude working on the daemon code, and it's about half done I guess. Lots of code is flowing into git everyday now.

Comments/flames as replies to the blog please. There's no anonymous posting as spammers like me too much. Thanks.

Cool new screenshots:

I would love to see a QT-based package manager and update icon using the PackageKit API. I'm quite prepared to make changes the the libpackagekit source if this is needed, I know I use a lot of gobject'isms. I can provide a private git server and add as much documentation as you guys need, I just need someone to take lead of such a project. Email the mailing list if you are interested. Thanks.

The other day I was asked in IRC if I did all the PackageKit coding myself. My response was “I do most of the C, but that's mainly boiler-plate stuff; the backend team do all the hard work“. The next question was “what is the development team like?” which got me thinking:

There's some top class guys doing a lot of work behind the scenes that need some recognition:

• Robin Norwood, new to the project, already rocking with expanding Description with package size and the file list in the daemon and client library.
• Luke Macken, a yum dude, helping to add unimplemented backend functions and fixing the yum backend.
• Tim Lauridsen, another yum dude that is always super quick and efficient. This guy is a yum legend.
• Tom Parker, the apt dude, although he's generally a whizz with C and C++ and general daemon stuff.
• Ken VanDine, the main conary dude, always great for bouncing ideas off and great for thinking outside the box. Always a friendly face in the irc channel.

There's other people as well (sorry to those I left out!) but these guys above are the “core” developers thus far. If you want to get involved, grab an entry from the TODO, email the mailing list and start hacking. We normally hang out in #PackageKit on freenode and are normally a friendly bunch.

If you're not a coder then you can help too. Check out the sources and compile and test test test like there is no tomorrow. Above all else, PackageKit needs more people to talk about it to raise the profile. Articles for news blogs or magazines would be great (email me if interested) – basically anything to raise its profile in the Linux community. I know I'm posting pretty frequently on p.g.o, but the majority of developers will probably miss these. Thanks.

Now if you double click on a rpm/deb file you will get the following UI:

You always get asked for the admin (or user) password so that this can't be abused by a malicious script when you have asked PolicyKit to remember your password.

We're a couple of weeks from the release of 0.1.0. There are no DBUS API changes planned in the near future, and we're just going though the list of blockers for release.

Join us in #PackageKit on freenode if you get stuck or you want to ask any questions. Thanks.