On Tue, 20 Jun 2006, Sukant Hajra wrote: > I know this is a new package, so I'm not too worried about these issues, > but although I find the scripts in this package a nice and interesting > compilation I feel as though it doesn't emphasize configurability right > now. It seems as though you're really trying to set up everyone's > computer all at once. This is IMHO too much like other distributions > and not what I am used to in Debian. To make such a system flexible, > I'd try to emulate what apache does. Here's my suggestions:
Thank you for all your suggestions, however note that I wan't all laptop to just have working ACPI so my intent is definitely to "setup everyone's computer all at once". Also I'm not the upstream of this package, Matthew Garrett created it for Ubuntu and I don't plan to invest significant work into it given that Matthew said that he will be working towards more standardized (and cleaner) ACPI stuff within freedesktop. In other words, this package is for today's needs (and probably etch) but certainly won't be the final solution to ACPI handling (post-ecth). Of course, if you feel like helping maintaining the package I would consider any patch like that you would propose in that direction. > 1) Don't put all the events of the package into the events folder. > /usr/share/acpi-support/events/ and allow the user to manually symlink > or copy them to the events folder. In the meantime, I _can_ make an > events.enabled directory in /etc/acpi/ and use the --confdir switch with > acpid to use that folder instead. We don't have the same notion of "user". A typical user won't symlink anything like that. > 2) I would also use a symlink approach for your ".d" directory > run-part'ing (similar to what Debian does with the /etc/init.d/ and > /etc/rc?.d/ directories). Not everyone wants to resume and suspend with > all those options in that order. I see that you've indicated that all > these action scripts are package conffiles. I'm not sure I like this > approach. I like the idea that you can develop these scripts with time, > and these changes can just roll into play via the symlink. For that > matter, maybe it makes sense to put _all_ the action scripts in > /usr/share/acpi-support/actions/ and not make them conffiles at all. Conffiles preserve local changes so it's necesseary given that you may want to disable some of them... but in the typical cases (no local changes), the scripts will be automatically updated and they will evolved over time like you would expect. > 4) acpid and your package put action scripts in /etc/acpi/, but > laptop-mode-tools puts these scripts in /etc/acpi/actions/. Personally, > I like the all the action scripts and supporting ".d" directories in > /etc/acpi/actions/. It seems cleaner, but as long as there's some > consistency, I don't really mind either way. It would be nice if you > could talk to the acpid and laptop-mode-tools and come up with some > convention on how to organize the directory heirarchy and symlinks. This could be a good idea, indeed. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/
