Richard Hughes posted information about the current PackageKit development. Recently PackageKit become capable of managing repositories and performing automatic updates with GUI support. Additionally, version 0.1 will be released these days and there is also work under way to create a KDE/Qt GUI.
PackageKit now includes the feature to switch repositories on and off. This is indeed useful for most Linux users out there since almost every user includes at least one more repository than the standard repositories (most often the additional repository comes along with non-free software). Of course average computer users are only supposed to change these values when they are advised to do so by the computer support or by a (good) howto – but there might be situations why this can become necessary, and in such cases a GUI is always better than the command line (this is the opinion of someone who is a voluntary help desk for years now).
As another feature PackageKit is now also able to notify when automatic updates are performed. The user can also cancel the task until further notice. The idea is that the automatic update is only done when the computer is idle (screen saver) and has a network connection (NetworkManager is used for that). If that is the case the user is still notified in case he wants to do something else or is short in front of a meeting or similar where he needs the absolute reliability of the machine.
Besides these new features of PackageKit itself we might see a KDE/Qt GUI in the near future: Adrien Bustany has started working at this and already published first results (Qt bindings). It would be really great to see native PackageKit support in for example KDE 4.1.
Speaking about future releases: the first official release of PackageKit is around the door: it was announced for this week and should therefore arrive soon. Besides the technical numbering for better planing and packaging such a release is also a declaration: PackageKit is stable enough to test it the first time. The APIs have matured up to a certain point and it is now worth looking at it.
And indeed: the Foresight distribution plans use PackageKit as their native frontend in the future. Congrats to the PackageKit team for that!
Besides these larger news the development goes on at high speed: the PackageKit team implemented local file install, support for new repository GPG keys and support for rollbacks. As usual, if the feature will work on your system depends on the backend and how far the backend supports these actions. In case PackageKit gets more spread (and I really hope it will do so) I wonder if we will se more development in the backends to better support PackageKit. Usually package management developers are very stubborn but PackageKit could even change that.
And maybe in some months PackageKit could start replacing the distribution specific tools slowly but steadily (relax, just for the average users!). That would be a silent, but large and really necessary revolution.
/home/liquidat 
The Qt version of PackageKit in development wastes memory because it actually links to GLib instead of speaking to it via DBUS. If it is included in KDE, it will mean KDE depends on GLib and will have to core libraries that do the same thing: Qt and GLib. That would suck in terms of performance and memory consumption.
I thought glib dependency was removed at some point
Well I do hope Packagekit catches on, the list of things horribly wrong with desktop Linux is rapidly getting shorter and packagekit fixes one of the big issues.
Qt4 since 4.2 uses GLib event loop, so (afaik) that means KDE4 will already link against GLib (in)directly.
Sutoka: The GLib loop in Qt4 is _optional_ (must be specified at compile-time) and quantifiably slower than Qt’s native loop. If we don’t want KDE to start out at a disadvantage compared to GNOME (which uses GLib natively), I say keep GLib out.
Using the glib event loop in Qt 4 glib is a necessity to allow apps using one event loop to use libraries using another. For example, it allows GTK+ apps to support KDE file dialogs without ugly event loop hacks like we’re currently using in TiLP, TiEmu and GFM (http://lpg.ticalc.org).
Forgive me for being sincere, but I think we just added a +1 on that list. Or perhaps to another list – the list of horrible software design mistakes.
Actually, what the designers tried to achieve was to create a common “facade” above all the package management libraries. This is one of the most basic design patterns.
However, instead of simply implementing this facade as a layer above the native P-M libraries, the developers decided to use IPC and a daemon/client model.
My question is: Isn’t that a huge performance loss? We have to spend processor power and memory for both the server and the D-Bus components in PackageKit.
What is PackageKit (the current design) able to do and the “facade” implementation isn’t?
@Martin, have you checked the reasons outlined for the client/server model? Otherwise the judgement “horrible” might be a bit rash.
So, to repeat others: PackageKit’s design is a client/server model on purpose. The actual advantages are:
– easy development of new GUIs (DE independence)
– it can operate in the background (automatic updates, etc.)
– it’s asynchronous: it can make usage of task queues and additionally does not block any further usage (most backends are locked if you use them)
– X crashes or other kinds of crashes are even more unlikely to cause any trouble
Most of the points above cannot or can hardly be implemented by using a facade I think, especially the asynchronous part would be very tricky. But you can also ask the developers of PackageKit directly if you want to discuss that more detailed (I’m not a developer…).
@Kevin
“Using the glib event loop in Qt 4 glib is a necessity to allow apps using one event loop to use libraries using another. For example, it allows GTK+ apps to support KDE file dialogs without ugly event loop hacks like we’re currently using in TiLP, TiEmu and GFM (http://lpg.ticalc.org).”
Does that mean that there will be posiibility of native KDE file dialogs in Gimp or Firefox?
koko, there’s kgtk for that.
http://www.kde-apps.org/content/show.php?content=36077
@Stefan,
I know that. But I would like to see this integration not as “a quick-and-dirty LD_PRELOAD hack ” that works only for some apps
Thanks for the blog and praise! If you guys have any concerns, join us on #PackageKit on freenode, or just email the mailing list. Thanks.
Richard: You’re welcome – and keep up the great work, I will try to spread the word 🙂