Category: Uncategorized

Translations:

• Updated Norwegian bokmål translation (Kjartan Maraas)
• Add Polish translation (Piotr Drąg)

New features:

• Show an icon when we are waiting, to give feedback when yum is waiting for a command line tool to release the lock (Richard Hughes)
• Connect up the Requires button in the toolbar (Grzegorz Dabrowski)
• Add a desktop icon for pk-repo (Richard Hughes)

Bugfixes

• Use the new API in PackageKit to get the cached data (Richard Hughes)
• Use a local copy of libgbus to stop the startup race of gnome-power-manager, gnome-screensaver and pk-update-icon from preventing the update icon to show on first login (Richard Hughes)
• Spin the progress bar at the same speed between applications (Richard Hughes)

Tarball available here.

New backends:

• A SMART backend (James Bowes)
• A PiSi backend (S.Çağlar Onur)

New features:

• A better, easier to use website (Richard Hughes)
• Added missing install-file.py so we can do local rpm installs (Tim Lauridsen)
• Be ultra-paranoid about validating input from the user (Richard Hughes)
• Send SIGQUIT and then SIGKILL after a little delay, so we can clean up the backends nicely by unlocking when we cancel (Richard Hughes)
• Add resolve functionality in pkcon to allow non-package_id use, for instance 'pkcon remove gimp' now does the right thing (Richard Hughes)
• Display a pulsing progress bar for no-progress-updates and percentage-update that is shown when using a console (James Bowes)
• Remove the hard dependency on NetworkManager so other networking stacks can be used instead (S.Çağlar Onur, Richard Hughes)
• Add a filter parameter for Resolve() so we can do the filtering in the spawned backend without duplicating code (James Bowes, Richard Hughes)
• Substantial additions to the box backend (Grzegorz Dabrowski)
• Add GetRepoList and RepoEnable to the yum backend (Tim Lauridsen)
• Add bash completion script for pkcon (James Bowes)
• Get the repo list for the aplm backend (Andreas Obergrusberger)

API changes:

• Store the transaction database in /var/lib rather than /var/db (James Bowes)
• Don't expose the private list in PkTaskList, instead use verified functions to ensure we can't corrupt data accidentally (Richard Hughes)
• Don't export the private data array in PkClient or PkPackageListthis breaks API, so the library version has been bumped (Richard Hughes)

Bugfixes:

• Fix the resolve method parameter passingnow pk-install-package should work correctly (James Bowes)
• Fix all the copyright notices to be a standard GPL2+ boilerplate licence text (Tom Parker, Robin Norwood)
• Dist the local apt headers so the apt backend can be compiled from a tarball rather than just from git (Richard Hughes)
• Fix a 1-in-10 random daemon startup crash when backends do libnm_glib init, shutdown, init, shutdown repeatedly (Richard Hughes)
• Added locking in the yum backend to allow simultaneous use of the yum command line tool or yum-updatesd (Tim Lauridsen)
• Fix NoPercentageUpdates validity checking (James Bowes)

Tarball available here.

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 Daemon

• 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

GNOME Frontend

• 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.

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.

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.

EDIT:

Do any mandriva developers read p.g.o? Does anyone want to write a urpmi backend for PackageKit? Join the mailing list and start asking questions and we'll do our best to help you. Thanks.