On Thu, May 13, 2010 at 6:38 AM, Damyan Ivanov <[email protected]> wrote: > -=| Luca Niccoli, Wed, May 12, 2010 at 11:55:41PM +0200 |=- >> This whole scripts-in-/etc/acpi thing has already caused big >> troubles: >> IIRC acpid used to ship some of them, and people customized them, >> until at a certain point the maintainer (or upstream maybe) decided >> that they weren't supposed to be there and purged them. >> People started shouting, and there was madness, and there was blood. >> That's why I think that scripts should be keep far away from /etc/ > > It doesn't help. You get the shouting now too, don't you? :) > > The solution would be to make the scripts so good, that they don't > need any local changes. Not very easy, it seems to me, as new models > could need new workarounds. I find the need to change the scripts > normal, and making this harder a mis-feature. I haven't witnessed any > problems with eeepc-acpi-scripts caused by local script changes.
Another solution would be to have the scripts in /usr but check if a script with the same name exists in /etc and execute only that. > > For example, I don't want the 'Wireless ...' notification before > 'Wireless On/OFF'. Since other people seem to like it, one way to > please everyone would be to add yet another configuration variable. > Another is to let me change the script locally. > > Of course, one could argue that all the user notification stuff > doesn't belong in eeepc-acpi-scripts in the first place and escape > this particular can of worms. I think so. I've also tested in my 701 4G the Luca's branch up to: 899d605 (test if eeepc-laptop is loaded at the beginning of each acpi-script, just to be sure that we're on an eee., 2010-05-12) and deleting the Conflicts/Replaces: $self. I've upgraded through a local apt repository and everything went fine. The only "regression" was that the volume mute/up/down stopped working because of this commit: ef84e9c (Turn off volume handling by default, since it conflicts with most desktop environment., 2010-04-23) Although I agree with the changes it is a regression and it has nothing to do with the compatibility with acpi-support. Maybe we can find a way to detect this the same way we detect if gnome-power-manager is running. Thanks, Santi _______________________________________________ Debian-eeepc-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debian-eeepc-devel
