Control: severity -1 wishlist On Thu, Jun 27, 2019 at 09:00:38PM +0200, Michael Biebl wrote: > Am 24.06.19 um 00:46 schrieb Ivo De Decker: > > acpi-support depends on it, so removal is not possible. And even if it was, > > it > > would probably be too late for that. > > > > Tagging this bug buster-ignore accordingly. > > Ok, I missed that. While this is unfortunate, I would still like to keep > this bug report as RC, so users of pm-utils are properly notified that > it is better to not use this package in buster.
But, as I repeatedly asked and you did not answer: WHY would it be better to not use this package in buster? Could you please name a case where it's harmful? Or even name a replacement that fits its use case and actually works? > Hopefully we can sort this out properly in buster+1. If you demand that obsolete quirks are deleted, that can be done. But that's in no way a bug of RC severity -- "wishlist" is appropriate unless you can demonstrate a quirk that actually can cause serious damage. And about the last part... after going out of my way to try to debug a certain broken piece of software that's not my itch to scratch, I was rewarded by my new expensive machine failing to power on, with main remaining suspiction being invalid pokes specifically to power management. Fortunately, after a few hours of random panicked actions such as reseating all motherboard-mounted pieces of hardware and so on, it did finally start up. Thus no -- there's no way I'm going to try that again. If you wish for a clean-up... at this moment I can't spare any real tuits, but we're in deep freeze anyway. _Then_ I, or someone else, can consider looking at this _wishlist_ thing. I obviously care mostly about my personal use cases -- none of machines I own match any of the quirks -- thus, if per your advice as the former maintainer, the quirks should go, then I have no means to test them anyway. Not can I test support for Apple PMU (I don't know how many people have/care about powerpc Macs). But... as the quirks affect only old machines, which were already there by the time you maintained the package, what's exactly the problem with them? Especially one that would warrant urgent action. I can drop that if you wish, but the package itself is needed to suspend _my_ hardware. I'm concerned with breaking other people's toys, though... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This ⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project. ⠈⠳⣄⠀⠀⠀⠀
