Day: September 19, 2007

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.
 

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.

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.