Comment 15 for bug 267141

I'm personally against dropping the patch, for the following reasons:
1. This won't stop people who want to use uswsusp from using uswsusp.
2. If the user has installed uswsusp, then, since it's in universe, it should mean that the user has explicitly chosen to use it
3. Dropping the patch would make people who need/want to use uswsusp to rebuild pm-utils with the patch

Matthew Garret disabled the s2ram build because many people decided to use uswsusp instead of reporting bugs in Ubuntu's default suspend code. This means that the rest of us who DO want to use s2ram cannot use it without rebuilding uswsusp. I don't like to put things too harshly, but my personal opinion about this is: this was a very stupid move, stepping around the matter rather than fixing it. If uswsusp broke stuff for some people, then ask them to remove it. Don't start messing up packages just because you feel like fixing stuff for people who wrongly installed a package that wasn't meant for them to begin with. I sincerely hope this doesn't carry to disabling s2disk as well, or just removing the entire uswsusp package altogether.

The way I see it, there are two (acceptable) ways to go about fixing this whole matter:
1. Re-enable s2ram. If people complain things break, tell them to remove s2ram, and mark their bugs invalid.
2. Hack pm-utils code into not looking at s2ram.
In both cases, I would recommend that uswsusp be dropped from Recommends to Suggests in pm-utils.

Method #1 would reverse Matthew Garret's change, and, I believe is the right way to go about things. If we keep stepping around this matter, we'll eventually encounter a greater problem than this. In fact, this whole bug came from disabling s2ram in the first place.

Method #2 would bring things back to how they were before ubuntu2. I wouldn't say it would bring things to how they were back in Hardy, because in Hardy, pm-utils looked for s2disk and s2ram in the wrong places (/usr/sbin instead of /sbin), and so uswsusp didn't work in Hardy anyway.