home *** CD-ROM | disk | FTP | other *** search
/ Clickx 115 / Clickx 115.iso / software / tools / windows / tails-i386-0.16.iso / live / filesystem.squashfs / usr / share / doc / sysv-rc / README.Debian < prev    next >
Encoding:
Text File  |  2012-03-26  |  2.2 KB  |  47 lines

  1. README for sysv-rc
  2. ------------------
  3.  
  4. Policy requires that maintainer scripts use update-rc.d to register and
  5. deregister initscripts.  An unfortunate result of this policy, combined
  6. with shortcomings in current update-rc.d implementations, is that there
  7. is no way for maintainer scripts to change the sequence number of an
  8. initscript that has already been registered if and only if its sequence
  9. number has not been changed by the administrator.  update-rc.d *never*
  10. changes the sequence number of an already registered initscript, even
  11. if its sequence number has not been changed by the administrator.
  12. There are no plans to fix this problem.  Therefore, if it is necessary
  13. to change the sequence number of an initscript in order to fix a bug
  14. then the maintainer script should go ahead and do:
  15.  
  16.     update-rc.d -f <scriptname> remove
  17.  
  18. before the new update-rc.d call, even though this overrides out any
  19. administrator changes.
  20.  
  21. Migrating to dependency-based boot sequencing
  22. ---------------------------------------------
  23.  
  24. Migrating to the dependency-based system of boot sequencing (using LSB
  25. headers) is non-reversible, and renders obsolete the legacy system of
  26. static sequence numbers. Please note that any boot sequence changes
  27. made locally will be lost in the migration, and must be reimplemented
  28. in terms of dependencies. However, the new system is recommended for
  29. several reasons.
  30.  
  31.  * initscripts can be made to run more efficiently via parallelized
  32.    execution strategies (see $POINTER_TO_ENTICING_BOOTCHARTS);
  33.  * boot and shutdown ordering is calculated on the basis of the
  34.    dependency information declared within each init.d script, ensuring
  35.    that the sequence is optimized for the set of packages installed;
  36.  * problems introduced by new or upgraded packages can be detected and
  37.    averted - the boot sequence is only modified if it is safe to do
  38.    so.
  39.  
  40. It can also bring benefits for Debian package development, and for
  41. admins maintaining local software, since it eliminates the difficulty
  42. of fitting an initscript into the boot sequence between existing
  43. services with adjacent sequence numbers.
  44.  
  45. It is also a step in the direction of boot systems better suited to
  46. the asynchronous nature of the Linux-2.6 kernel boot process.
  47.