Bug#426939: split acpi-support into more than one package
tags 426939 wontfix thanks > I'd rather improve the organization of the package (which it > definitely needs) than splitting it up. You see, it's not a large > package, it's just a bit disorganized. And that's the fault of > upstream (which is Ubuntu). Anyway, I want to avoid at all cost > that the user needs to manually select the right package for > his/her laptop to work. The only problem here is really that these > files are in the config directory, while they really contain > package code. I'd much rather fix that instead. Thanks for your time. -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#426939: split acpi-support into more than one package
Raphael Hertzog wrote: On Mon, 18 Jun 2007, Bart Samwel wrote: Well, it would allow me to use acpi-support and actually make sense of /etc/acpid/* by removing all the stuff that I will never need. This is Debian, after all... I'd rather improve the organization of the package (which it definitely needs) than splitting it up. You see, it's not a large package, it's just a bit disorganized. And that's the fault of upstream (which is Ubuntu). You must keep in mind that acpi-support is something that's supposed to not exist. It's only filling gaps so that it actually work with the deficiencies of the drivers and the hardware. Yeah, I do keep that in mind. So I want to keep the differences to upstream small as well -- but I do want to fix the bugs that do appear. OTOH, the situation basically means that architectural wishlist items are unlikely to be solved, unless the upstream cooperates. In the long term, the goal is to reduce the number of different cases and certainly shrink the size of the package. Maybe move some functionalities in other parts of the system (gnome-power-manager, acpid, etc). Shrinking the package would be a good thing. I think there are some potential problems with the target locations you mention as well: - acpid is a very basic mechanism daemon. Many of this stuff doesn't belong in the base ACPI mechanism either. - gnome-power-manager is only fine if you're running gnome. OTOH acpi-support works too if you're on a bare terminal. We already defer some of our control to gnome-power-manager and its KDE twin when they're running, but we can't assume they always are. [rant] The first time I saw gnome-power-manager presented (I think it was at FOSDEM 2006) I immediately had strong objections to the idea of a gnome-specific power management daemon. IMHO there should be a *system-wide* power management policy daemon, controlled by a desktop-specific UI and a system-wide policy file. It's just crazy that the only way to prevent users from shutting down/hibernating/putting to sleep a system is by firewalling the dbus messages that are sent to the hal daemon. And that the first user to log in gets to run the "master" gnome-power-manager daemon under his own account. Perhaps this model is fixed by now, but still, the basic design was so flawed and single-user-Ubuntu-Gnome-focused it was basically unfixable. (I'm sorry if any of the original authors are listening in, this was just my initial impression of the whole thing.) [/rant] Anyway, now that we're thinking about this already, for the phasing out of acpi-support I would be thinking of steps such as: 1. Splitting off the sleep/hibernate *mechanism* (as opposed to the policy) into one or several different packages. We could have a virtual package "hibernation", provided by several implementation packages, such as the "hibernate" package, or a split-off version of acpi-support's own hibernation code. This would also give us a clean way to get rid of this wishlist item: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405563 2. Moving all of the special key conversion stuff into the kernel. These should be generic keys, you shouldn't need to convert this stuff. Actually, I saw some LKML activity recently that indicated that a project to do this, and to make most laptop keyboards "just work" is underway. The project is titled "Unf*ck my keyboard", see for instance this message: http://lkml.org/lkml/2007/5/31/137 3. Laptop-specific mechanisms for screen brightness should be included in kernel drivers for /sys/class/backlight. 4. As a final nail in the coffin of acpi-support, the remaining policy stuff should be moved into a desktop-agnostic "system event and power policy daemon", which would basically be a split-off gnome-power-manager back-end with a system-wide default policy configuration file. This daemon would also have to control some additional policy regarding the response to certain acpi events (such as special keys being pressed). I guess that (2) and (3) are slowly being done already. No work is being done towards something like (1) and (4). I'm actually considering doing (4) myself. I've actually been considering this for quite some time because the current situation with the various power-management policy daemons and packages is irritating the hell out of me. :-) So I think that reorganizing this package is mainly lost work unless you manage to become upstream together with Ubuntu. Matthew Garrett is not interested in that but you might want to ask Paul Sladen who made the 4 or 5 last Ubuntu uploads. I will definitely ask him to consider this. With joint efforts we might be able to reduce acpi-support a little sooner rather than later. BTW, I know this has been a pretty long rant and that many of the things I wrote here are probably not going to happen soon. I'm just trying to figure out what future directions there might be, and what I could do to ma
Bug#426939: split acpi-support into more than one package
On Mon, 18 Jun 2007, Bart Samwel wrote: > >Well, it would allow me to use acpi-support and actually make sense > >of /etc/acpid/* by removing all the stuff that I will never need. > >This is Debian, after all... > > I'd rather improve the organization of the package (which it definitely > needs) than splitting it up. You see, it's not a large package, it's > just a bit disorganized. And that's the fault of upstream (which is > Ubuntu). You must keep in mind that acpi-support is something that's supposed to not exist. It's only filling gaps so that it actually work with the deficiencies of the drivers and the hardware. In the long term, the goal is to reduce the number of different cases and certainly shrink the size of the package. Maybe move some functionalities in other parts of the system (gnome-power-manager, acpid, etc). So I think that reorganizing this package is mainly lost work unless you manage to become upstream together with Ubuntu. Matthew Garrett is not interested in that but you might want to ask Paul Sladen who made the 4 or 5 last Ubuntu uploads. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#426939: split acpi-support into more than one package
Hi Martin, martin f krafft wrote: also sprach Bart Samwel <[EMAIL PROTECTED]> [2007.06.16.2209 +0100]: don't kill me, instead split acpi-support into acpi-support-ibm, acpi-support-toshiba, … please? :) Sorry, I think I have to refuse this one (without killing you ;-) ). There are various reasons for not wanting this: Thanks for taking the time to argue your position. wontfix is acceptable for me, but I still challenge it a bit below: OK, let me try to respond to your concerns again! * The acpi-support package is intended to contain a library that associates laptop models and the required package behaviours. Many of the behaviours are not as clear-cut as "toshiba" vs. "ibm" versus "dell" versus "asus". so how about acpi-support-common? Like I said, the parts aren't so cleanly separable. Most of the stuff *is* common. :-) * apt cannot detect the specific laptop model, this detection is left to acpi-support. Therefore, acpi-support *must* be able to support all laptops out-of-the-box, *or* it must detect the laptops and install the additional packages automatically. But this would again require knowledge about the existing laptop models in the core package, which would defeat the entire purpose of splitting the package up! you can provide acpi-support which depends on acpi-support-*. Please see how xorg-video-drivers-all works. I see, but that means that you always have to install everything anyway. Unless you split into -common, - and -all. But that would be a REALLY complicated solution, while the laptop-specific stuff is REALLY small. Definitely overkill. * The split would yield a lot of *very* small packages, consisting only of a couple of settings and a tiny number of config files. This is probably overkill. Well, it would allow me to use acpi-support and actually make sense of /etc/acpid/* by removing all the stuff that I will never need. This is Debian, after all... I'd rather improve the organization of the package (which it definitely needs) than splitting it up. You see, it's not a large package, it's just a bit disorganized. And that's the fault of upstream (which is Ubuntu). Anyway, I want to avoid at all cost that the user needs to manually select the right package for his/her laptop to work. The only problem here is really that these files are in the config directory, while they really contain package code. I'd much rather fix that instead. Cheers, Bart
Bug#426939: split acpi-support into more than one package
also sprach Bart Samwel <[EMAIL PROTECTED]> [2007.06.16.2209 +0100]: > > don't kill me, instead split acpi-support into acpi-support-ibm, > > acpi-support-toshiba, … please? :) > > Sorry, I think I have to refuse this one (without killing you ;-) ). > There are various reasons for not wanting this: Thanks for taking the time to argue your position. wontfix is acceptable for me, but I still challenge it a bit below: > * The acpi-support package is intended to contain a library that > associates laptop models and the required package behaviours. Many > of the behaviours are not as clear-cut as "toshiba" vs. "ibm" > versus "dell" versus "asus". so how about acpi-support-common? > * apt cannot detect the specific laptop model, this detection is > left to acpi-support. Therefore, acpi-support *must* be able to > support all laptops out-of-the-box, *or* it must detect the > laptops and install the additional packages automatically. But > this would again require knowledge about the existing laptop > models in the core package, which would defeat the entire purpose > of splitting the package up! you can provide acpi-support which depends on acpi-support-*. Please see how xorg-video-drivers-all works. > * The split would yield a lot of *very* small packages, consisting > only of a couple of settings and a tiny number of config files. > This is probably overkill. Well, it would allow me to use acpi-support and actually make sense of /etc/acpid/* by removing all the stuff that I will never need. This is Debian, after all... -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
Bug#426939: split acpi-support into more than one package
Hi Martin, > don't kill me, instead split acpi-support into acpi-support-ibm, > acpi-support-toshiba, … please? :) Sorry, I think I have to refuse this one (without killing you ;-) ). There are various reasons for not wanting this: * The acpi-support package is intended to contain a library that associates laptop models and the required package behaviours. Many of the behaviours are not as clear-cut as "toshiba" vs. "ibm" versus "dell" versus "asus". * apt cannot detect the specific laptop model, this detection is left to acpi-support. Therefore, acpi-support *must* be able to support all laptops out-of-the-box, *or* it must detect the laptops and install the additional packages automatically. But this would again require knowledge about the existing laptop models in the core package, which would defeat the entire purpose of splitting the package up! * The split would yield a lot of *very* small packages, consisting only of a couple of settings and a tiny number of config files. This is probably overkill. All in all, I think these are enough reasons to not want this. If you come up with a compelling case you can still change my mind of course, but for now I'm considering this a "wontfix". Cheers, Bart
Bug#426939: split acpi-support into more than one package
On Sat, 16 Jun 2007, Bart Samwel wrote: > All in all, I think these are enough reasons to not want this. If you > come up with a compelling case you can still change my mind of course, > but for now I'm considering this a "wontfix". FWIW, I agree. Bart, BTW I receive the discussion on bug reports via the PTS so you don't need to put me in copy (unless you really want special attention from me). I guess it's the same for Loïc. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
Bug#426939: split acpi-support into more than one package
Package: acpi-support Severity: wishlist don't kill me, instead split acpi-support into acpi-support-ibm, acpi-support-toshiba, … please? :) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.20-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems signature.asc Description: Digital signature (GPG/PGP)
