[packagekit] org.freedesktop.Hal.Device.SystemPowerManagement and the user

[Richard Hughes]

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 the sleep 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.

http://people.freedesktop.org/~hughsient/temp/pk-inhibit.png

But, as you 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 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.

Backend authors should really ensure that allow-interrupt(b=allow_kill)
is sent when we are searching, and also when we are in the download
phase of the other transactions. By default, nothing is interruptable so
you actually have to implicitly call this in the backend if it's safe to
do so.

If you're unsure on if allow-interrupt should be sent, think what would
happen if the user did ctrl-c - if bad stuff _can't_ happen then just
make sure allow-interrupt is set to true.

Yell if you need any help, thanks.

Richard