Day: October 13, 2007

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.