[Debian-eeepc-devel] eeepc-acpi-scripts integration: please test

[Santi Béjar]

On Thu, May 13, 2010 at 6:38 AM, Damyan Ivanov <dmn at debian.org> 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