The PackageKit team have been rocking recently with lots of new features and bugfixes. There is yum group support thanks to Tim, and soon there will be other backends supported too.
The screenshot below just shows what pk-application looks like with groups support. All the names are translated into the session users locale, as you would expect. Comments welcome.
pk-application with groups support
James Bowes is rocking more; PackageKit now has the beginnings of a smart backend. Next step, world domination. Early this week there will be a 0.1.1 release with more cool features, and lots of nice fixes.
James Bowes has been rocking on PackageKit recently. This is some text client code he is working on right now:
Quoting James, “welcome to the future of user interfaces…”
The new Packagekit website is online – comments welcome, thanks!
- The first public release of PackageKit!
- New gobject client library for session software to easily talk to PackageKit.
- Asynchronous API that does not block.
- Daemon that can queue and manage multiple simultaneous blocking and non-blocking transactions
- Client applications (pkcon and pkmon) that interact with PackageKit on the command line without any GUI dependencies
- Many compiled and scripted backends: conary, yum, apt, box, alpm
- Comprehensive docbook documentation
- Daemon configuration parameters in etc
- Module level unit tests as standard
- Python backend and frontend helper libraries
- Transaction logging and capability exports for GUI tools
- HAL locking supported for not-to-be interrupted phases of the transaction
- NetworkManager integration for network state (other network detection stacks can also be used in the future)
- PolicyKit integration for fine-grained permission control
- The first public release of gnome-packagekit!
- Current applications and tools:
- pk-application: A more advanced package browser where you can install, remove and get details about installed and available packages.
- pk-update-icon: A session process that checks for updates using PackageKit and optionally applies them automatically.
- pk-install-file: A helper to allow rpms and debs to be double clicked and installed with dependencies automatically.
- pk-install-package: A helper to allow packages to be installed with a progress UI, for instance openoffice-clipart.
- pk-prefs: The preferences tool that sets update checking frequency and other package session preferences.
- pk-update-viewer: A simple application to show the updates available, and more information about each update.
- pk-backend-status: A development tool to see what capabilities the backend author have provided.
- pk-transaction-viewer: A tool that lets you see what was updated, installed or removed and optionally rollback to an old checkpoint.
- pk-repo: A tool that lets you enable and disable installed repositories.
- Some initial translations
- A simple help file.
Tarballs available from my freedesktop page. RPM's available here. My thanks go out to all those who made this possible.
Not very important in the grand scheme of things, but some people want to be able to enable and disable different repos.
pk-repo, which took about 10 minutes to create…
The frontend is done, the backend just needs adding. This should be pretty trivial, it just needs support in the backends. Of course, this will work for all backends and distros and is not distro specific. PolicyKit will be used again to enforce the permissions for changing the repo files.
They'll also be method to set arbitrary data, for tools like distro upgrade tools. A distro upgrade tool isn't something I want to add in PackageKit, although it should be simple to knock something up in python just to execute backend specific standards. There's a python helper library shipped for stuff like this. For example, a foresight distro update tool could just call RepoSetData(“conary-set-download-url”, “http://new-version.org”) and then UpdateSystem().
Don't expect this to work properly for 0.1.0 next week, this is a feature preview.
At the last GUADEC I mentioned to mclasen and hadess after a few beers that I wanted to look into a package management system service. I talked to davidz and he thought it was a good idea but very very difficult to do because of the technical difficulties and all the politics involved. I like difficult. I finished my university masters, and spent a few weeks just drawing UI sketches and prototyping server and client code. I announced what I was working on in my blog and to various mailing lists, and setup a public git repo on my tiny 500MHz EPIA server. Personally, I've probably been working on PackageKit an hour or so every day. After a couple of weeks, a few hundred commits and few developers we moved the git and web server to a proper server in a colo, kindly provided by kenvandine and elliot. Now we have nearly a dozen developers, half a dozen core developers and a busy, thriving mailing list. We've got formal commitment from a couple of distros for their next release, and other distro announcements that we can't yet share. Early next week I will release the first public release, 0.1.0, of PackageKit and gnome-packagekit. In 6 weeks we will have achieved something that many people said could not be done, with a small team of developers that want to do something for the community. I'm not sure what the point of this blog is, but if nothing else it's saying it's very easy to scratch an itch given a good idea, enough motivation and a strong desire to make something better. At GUADEC2008 I'll gladly do a presentation on how we've done all this so fast, and how we see the future of packagekit. Maybe then the frequency of my blog posts might reduce. :-)
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.
Pretty crappy UI…
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.
This is in git now.