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:
This is in git now.
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: http://fedoraproject.org/wiki/StatelessLinux 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).