Package: acpi-support
Version: 0.84-1
Severity: wishlist


Hi,

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:

1) Don't put all the events of the package into the events folder.
Rather put them into /etc/acpi/events.available/ or
/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.

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.

3) If you're really stoked about the idea of having "one package that
fits all" then I suggest you have a debconf option to enable (install
symlinks for) all the events and actions upon the package's
installation.

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.

I think you get the idea of what I'm driving at here.  I just feel that
with this many configuration scripts, the user should be given the
opportunity to more easily select what's appropriate for their system.
As long as the layout of the scripts and symlinks is documented in a man
page, README file, etc., I think this is the way to go instead of the
monolithic approach you have right now.

Regards,
Sukant


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (90, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-hole
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages acpi-support depends on:
ii  acpid                         1.0.4-5    Utilities for using ACPI power man
di  dmidecode                     2.8-2      Dump Desktop Management Interface 
ii  finger                        0.17-9     user information lookup program
di  hdparm                        6.6-1      tune hard disk parameters for high
di  laptop-detect                 0.12.1     attempt to detect a laptop
di  lsb-base                      3.1-10     Linux Standard Base 3.1 init scrip
di  powermgmt-base                1.24       Common utils and configs for power
di  radeontool                    1.5-3      utility to control ATI Radeon back
ii  toshset                       1.71-1     Access much of the Toshiba laptop 
ii  vbetool                       0.6-1      run real-mode video BIOS code to a
di  xbase-clients                 1:7.0.1-2  miscellaneous X clients

Versions of packages acpi-support recommends:
di  laptop-mode-tools             1.31-1     Scripts to spin down hard drive an

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to