org.freedesktop.Hal.Device.SystemPowerManagement and the user

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.

Published by


Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

One thought on “org.freedesktop.Hal.Device.SystemPowerManagement and the user”

  1. These changes reduce the window for failure, which is good (might want to add logic that requires say 15 minutes of battery life available even when on AC). But ideally we would have a system which was resilient to e.g. power loss in the middle of an update. Stateless Linux' two-partition model is one approach: Another would be to improve the various backends to be more journal-like. Which gets to the point that hopefully packagekit will reduce the duplication among backends (since all they really are now is way overcomplicated ways to download glorified tarballs over HTTP and run shell scripts with make-style dependencies).

Comments are closed.