Richard Hughes wrote: > On Mon, 2007-12-03 at 10:51 +0100, Stefan Seyfried wrote: >> On Sun, Dec 02, 2007 at 06:45:03PM +0000, Richard Hughes wrote: >>> On Sun, 2007-12-02 at 10:00 +0100, Michael Biebl wrote: >>>> 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) >>> Please don't do this. >> care to give a reason? I think this is very reasonable. > > What benefit does it bring?
It brings the benefit of not having a totally broken package. pm-utils is all but dead upstream. I made several requests and they went virtually unanswered. I even had to do all the leg work of getting pm-utils.freedesktop.org registered as a web host when I requested some sort of data. This is the only e-mail to the ML in 3 months. It's YARHTTGABFBOP. Yet Another RedHat Technology That Gets Abandoned But Forced By Other Packages. > >>>> and provide the pmu >>>> functionality (together with support for all the other quirks) in one >>>> single binary >>> No, that's no how it is supposed to be put together. >> Why? > > Because that's how it's put together on most of the big distros - and > more often that not it works, and most importantly people understand how > it works. Big distros defined as Red Hat / Fedora only? > >>>> , 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. >>> Why do you need to use pm-utils and uswsusp? Doesn't the kernel method >>> work? It sounds like this is packaged in an odd way. >> The kernel method is slow and has no support for splash screens. You cannot >> do s2both with it. > > I've never got the userspace splash fb to work on most of the systems I > was testing at RH. It sometimes broke working suspend. I've got nothing > against userspace suspend, it just seems kernel suspend seems to work > for more people. mm on the contrary I've heard a lot of success stories with userspace stuff when kernel stuff failed. > >>>> 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. >>> No. s2ram should just _do_ the suspend, not muck about with quirks and >>> poking pmu - the pm-utils infrastructure should do this. The "nasty >> i absolutely disagree. The only advantage that you get by doing it in >> ugly shell scripts is that you pull in lots of dependencies and are >> more susceptible to race conditions. Putting all the quirks into one >> binary (which should probably even be mlock()ed) makes suspend much >> less error prone. > > I don't think this is true at all. > > Richard. > Bring pm-utils back to life and I'll agree with you Richard. -- Doug Klima <[EMAIL PROTECTED]> http://dev.gentoo.org/~cardoe/ _______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
