Category: Uncategorized

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.

Today I stumbled on the following blog post – basically, it's a developer from gentoo saying that because PackageKit won't ask the user for compile flags it's unsuitable for use in gentoo. The author then goes on to define an overly complex abstraction for package management suitable for gentoo.

I've just been sent a new design proposal for the pk-prefs dialog:

Comments?

It's a lot more concise, and seems to represent the relationship between the sections better. I like it. Comments?