Why do we still ship hal-system-power-pmu / PMU support suboptimal in pm-utils

[Michael Biebl]

Hi,

apparently, the hal suspend script (hal-system-power-suspend-linux)
does not use hal-system-power-pmu anymore, so I'm wondering, why hal
still ships this binary?
Isn't the backend (pm-utils resp. pm-pmu) supposed to provide this
kind of functionality?

I also noticed, that pm-utils is still sub-optimal on ppc
architectures. E.g pm-is-supported does not seem to correctly detect
pmu support, and whenever pm-utils is installed, hal will use
pm-is-supported to set the power_management.can_* keys, thus g-p-m
will not offer this option anymore in the gui. See [1] for reference.
I have to add, that pm-utils in Debian does not ship pm-pmu (it was
removed by the Debian maintainer deliberately), as we tried to make
pm-utils an arch:all package (only shell scripts) and provide the pmu
functionality (together with support for all the other quirks) in one
single binary, s2ram from the uswsusp package [2]. Apparently this has
led to problems [3] for people using pm-utils, but don't have the
uswsusp package installed.

The question now is, where to put this pmu support: hal, pm-utils or s2ram?
I personally would like to remove hal-system-power-suspend-linux from
hal, pm-pmu from pm-utils (so pm-utils becomes a arch:all shell script
only package) and move all the nasty stuff into one binary, s2ram,
which then deals with stuff like poking /dev/pmu, VBE save/restore
etc.

I'd be interested in what others think about that issue.

Cheers,
Michael

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=452367
[2] http://packages.debian.org/sid/uswsusp
[3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450601

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?