[Pm-utils] Why do we still ship hal-system-power-pmu / PMU support suboptimal in pm-utils
mbiebl at gmail.com
Sun Dec 2 01:00:48 PST 2007
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  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 . Apparently this has
led to problems  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
I'd be interested in what others think about that issue.
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
More information about the Pm-utils