A pretty-useless debugging client for PackageKit I wrote in a few minutes:


Useful to PackageKit Hackers…

It basically allows you to see what the currently running backend can do, and what is left to implement. Some of the backends can't do all the actions, so this tool can show you what they should be able to do. It's not pretty, but it's for programmers, not end users.

PackageKit GUI Tools

Currently the name of the package management tool is “Manage Packages” in the GNOME menu. It's a way of searching for and installing or removing software in a fairly techy way. Fedora name the pirut tool “Add/Remove Software” and I'm sure other distros name the “installer” different things like “Software Installer”.

The update viewer is currently called “Update Viewer” as it's primarily a way of seeing what changed and the reason why, rather than a way to apply the updates (although it can be used to trigger that too).

As usual, I've currently chosen rubbish names….

I need some help on the menu names of these applications – some suggestions:

  • Manage Packages
  • Manage Software
  • Add/Remove Packages
  • Add/Remove Software
  • Software Installer
  • Package Installer
  • Package Update Viewer
  • Software Update Viewer
  • View System Updates

In the future there will also be a tool “Application Installer” that just has a list of common applications like “Pidgin” and “Abiword” and ratings and that sort of thing. This requires integration with the online desktop thing and needs some fleshing out from a design point of view before any code is written. I want to get the “system” tools written before I flesh out this idea.

Other name suggestions welcome, as usual. Reply via blog or email. Thanks.
 

What is a cache and why do I need to refresh it?

David posted a comment to my last blog entry with a sarcastic “What is a cache and why do I need to refresh it?”. He's got a valid point.

To me, having “refreshing a cache” in the status UI is much like the rationale for having both suspend and hibernate in the UI. The user shouldn't need to know the difference between suspend and hibernate as they are both ways of making the computer “sleep”. The reason why we have to expose both into the UI is that suspend is fast, but has volatility, and hibernate is slow but doesn't. This is just a technical design decision that is made due to other unfixable design decisions or hardware limitations.

I think it's much the same for refreshing a cache. The user shouldn't have to know what it is doing, it should just work, but the unfortunate drawback is that refreshing a cache can take quite a long time and during that time none of the other functionality like searching or getting the update list works until this is completed.

So, the short answer is that the cache is automatically updated on the first logon (20 seconds after the network comes up for the first time) and then every 12 hours after that. It will be per-session configurable in gconf for sure (as you don't want to suck 500k of metadata down a 14k dial up link….), and you can also force a refresh in the update GUI tool.

I welcome other more less-technical names for “Refreshing package cache” maybe:

  • Updating package lists
  • Updating software metadata
  • Refreshing repository data

Other name suggestions welcome. Reply via blog or email. Thanks.

Queuing PackageKit Transactions

I've just completed a big entry off the TODO: queuing transactions that can't be done in parallel. This means you can do RefreshCache and then GetUpdates straight away, and the latter will wait (async of course) for the first to finish. Before we just failed the second transaction which wasn't very nice. Also, when it's sane to do so, we run all queries (that don't write to the disk) in parallel with other tasks.


Grammar, yadda, yadda

The code is lightly tested, but seems to work okay for me. This was a bit of code that I had put off writing for a few weeks as it was always going to be tricky to do right.

There's also code in the daemon now to log transactions to the database that have potentially changed things. This is the first chunk of code needed for the rollback support for some backends, and also allows us to find out “what was updated yesterday because now java doesn't work”.

So basically what I'm trying to say is that there is lots of new code in git today, so expect it to break horribly. Please yell on the list if you find anything odd.

Current status of PackageKit backends

Well, hacking is going good. New backends are being developed and merged, and the underlying daemon is a lot more stable. There are now helpers for threaded backends, so in theory they are as easy to write as the external spawned backends. I've merged lots of patches this weekend, and only have two more things on the “complete before first release” list.

                   | conary | yum | apt | box | alpm | ----------------------------------------------------- refresh-cache     |   X    |  X  |  X  |  X  |      | get-updates       |   X    |  X  |     |  X  |      | update-system     |        |  X  |     |     |      | search-name       |   X    |  X  |  X  |  X  |  X   | search-details    |        |  X  |  X  |  X  |      | search-file       |        |  X  |  X  |  X  |      | search-group      |        |     |     |     |      | install           |        |  X  |     |  X  |  X   | remove            |        |  X  |     |  X  |  X   | get-depends       |        |  X  |     |     |      | get-requires      |        |     |     |     |      | get-description   |   X    |  X  |  X  |  X  |      | get-update-detail |        |     |     |     |      | 

So, all being good, I hope to release version 0.1.0 in the next few weeks.

PackageKit progress, and unit tests

Some people may have noticed that there was a flurry of activity for PackageKit in the last few weeks, and then nothing for a whole week. The reason is that I've finished my internment at Red Hat and now am on a graduate program for a large defence company. This is not the end of my OSS activity, so panic not. Working for Red Hat was great, and I would recommend it to anyone interested in working with the best open source company out there. This week was my first week at my new job, and rather hectic; so if I haven't answered your email I'll catch up with it on the weekend. So PackageKit. This week I've been moving around blobs of code and refactoring stuff, removing bodges and adding self check code in the daemon. It's not particularly interesting to blog about as it's not screenshottable. The daemon is a whole lot more sane now, and the API has improved lots in my opinion. There's still some more API additions we need to make (to get the update details for a particular package_id comes to mind..) but generally I think we are nearly there. I'm going to be working on more documentation for backend writers as what I've got now is a little hard to read. Backends are now compiled .so objects with optional external helpers. This removed the horrific gobject hacks I was using before, and actually makes a nice abstraction. It should be a lot easier for new backend writers to add a new backend into the tree, and makes it easier to test as you can now select the test or dummy backends at runtime rather than having to recompile. The yum backend is nearly complete, apt is about half done, conary similar, and a preliminary box backend has also been added. There's interest in adding pacman, zypp and emerge backends also. I want to apologise a little to the backend writers. I know I keep tweaking the API, moving files about, and changing the enum defines but I believe doing this early in the project will give us a complete system that is free from bodges around premature design decisions. I need to change a few enumerated types in the next couple of days, add the internal queuing API and add a whole heap more self tests and then I probably should release 0.1.0 to the unsuspecting public. Talking of which. I know self tests are not the most interesting bits of code, but they are pretty easy to add. If you are not a great C coder, but want to get your hands dirty with PackageKit you could help me write the simple tests. Most are of the type: /* check function does not explode with NULL */ ret=function(NULL); if (!ret) abort(); /* check return type*/ ret=function2(“dave”); if (ret != ENUM_DAVE) abort(); If you look the existing tests you'll see the sort of things we test for and the simple framework that we are using to make the tests a bit easier to write. Email me and I can tell you what needs to be done. Thanks.

PackageKit Update Viewer

People are odd creatures. Sometimes people want to see why different packages need to be updated and want more information about what the update will achieve.

Yes, I know I need a details box…

The pk-updates application will list updates and show more information if you click on an entry. There is no such information from yum yet (AFAICT), but I'm trying to design the signal to be powerful enough for the other backends and for yum when it gets that data.

If you click close, the application will close. If you click apply, then the application will close, and the update will continue in the background. Yay for async.

If anyone wants to fix any of the applications to match the GNOME HIG (or other spelling or grammar fixes), send me an email and I'll get you commit on my internal development server; I'm really no good at that sort of stuff. Thanks.

Application database icons

When pk-application gets packages that meet a search criteria it just prints the package name, version, summary and if it's installed or not. This is really bad from a UI point of view.

What I want is:

__________
[ ] packagename-version
[ ICON ] Translated short description
[________] [more]

Unfortunately, neither the translated short description nor the icon is present in a rpm or deb. This seems odd to me, as in Windows world an installer package gets to choose its own icon, although I appreciate there is usually a loader involved.

gnome-app-install hardcodes everything to ubuntu package naming and iterates on a mirror of the ubuntu servers picking out desktop files. This isn't ideal as it's ubuntu specific and requires quite a bit of manual fixing up and package specific checks. But it looks good.

So we have several solutions to this problem:

  1. Modify every packaging system to return a translated package name and icon for each package in the repo.
  2. Maintain a separate packagekit-data package which is just full of icon files and translated .desktop files, and a per-distro common_name->package_name database.
  3. Don't display an icon for the package and only show the icon of the group type.

Option 1 would require massive code changes in all the packaging formats and isn't really an option.
Option 2 is a never-ending-story and there would be a massive workload to keep the database up to date and the translations fresh. There would need to be some sort of web interface to keep everything updated without a deluge of patches.
Option 3 is what I'm doing now, but looks completely amateur compared to gnome-app-install.

So, ideas?