Bug in apmd debian scripts

[Chris Hanson <cph@debian.org>]

   Date: Thu, 25 Mar 2004 11:52:29 +0100
   From: Clemens Wacha <clemens.wacha@gmx.net>

   Hello,

   in /etc/apm/apmd_proxy script it says

   if [ we are going to suspend ]; then
	   run-parts /etc/apm/suspend.d
   fi

   in suspend.d you have symlinks to /etc/apm/scripts.d

   this does not work because run-parts only executes script but does
   NOT follow links to scripts

That was bug #238816, which is fixed in the latest version.

   And btw it's highly confusing that we have more than one possibility
   to run scripts on suspend/resume events
   1. from /etc/apm/event.d
   2. from /etc/apm/resume.d
   3. from /etc/apm/suspend.d
   4. from /etc/apm/other.d

   ... etc

   I'd vote for seperate dirs like
   suspend.d  (all suspend requests)
   standby.d (all standby requests)
   resume.d (all resume requests)
   battery.d (change battery request ( the request that tells us when
   battery is low)

   and other.d (for other change requests)

   and completely remove script.d because it doesnt work anyway and
   remove events.d because it makes thing more difficult than needed
   and its function is less obvious than the folder approach.

There are good reasons why this confusing system is used.

First, the "events.d" directory exists for backwards compatibility.
Until about two years ago, it was the only way to define APM scripts.

Second, the newer directories were created in order to give the user
more control over the ordering of scripts.  It's often the case that
suspend/standby events want the opposite sequencing from resume
events.  The separate directories aren't intended to be a way to
distinguish different kinds of requests, which should be done by
examining the script's arguments.

Third, the use of the "scripts.d" directory and symlinks allows all of
the actions for a particular subsystem to be in a single file,
separate from the time sequencing of each subsystem's actions.

This is not an ideal system, but it does provide enough flexibility
for most purposes.  If it's confusing, that is probably a shortcoming
of the documentation.

Thomas Hood has been working on an alternative system, in which the
event sequencing is controlled by statements inside the scripts.  This
promises to simplify things in the long run.

Chris