                 Maintainer notes for sysvinit

News
----
Last updated 16 May 2009

Stuff to implement
------------------
* Do not allow system to continue booting if both fsck and sulogin fail (#337444)?
* Make sulogin try /bin/sh and /bin/sash too (#40144, #43317)?
* Port bootlogd to use posix_openpt(3), since BSD PTs are now deprecated and
  /dev/pts _is_ now available at the time that bootlogd starts (...in Debian)?

Stuff to do after etch
----------------------
* mountnfs.sh: Don't start portmap

Ubuntu changes to backport
--------------------------
(none known ATM)

Stuff to send upstream
----------------------
debian/patches/fix-minor-warnings should be applied upstream.
So should a lot of the other patches.

src/Makefile should not set CC.

set -e
------
Note that many scripts do not use "set -e".  This is deliberate.
Instead, return statuses are checked.

PATH
----
* Current policy:
  + Leave unset if absolutely no pathless commands are run; otherwise...
  + set to "/sbin:/bin" in /etc/init.d/rc and in scripts that run prior
    to mountnfs.sh; otherwise...
  + set to "/usr/sbin:/usr/bin:/sbin:/bin".
  + Add "/lib/init" to beginning of PATH if readlink command or domount
    function used.  This will disappear once coreutils 5.94 makes it
    into testing, and we Depend on that.
* Question: Should we include /usr/local/sbin and /usr/local/bin too?
  I don't see this question addressed in Policy.  Ref: #227540

Dependencies
------------
To go away:
* sysvinit Pre-Depends on initscripts, sysv-rc | file-rc so that the
  conffiles in the old monolithic sysvinit package are taken over by
  the initscripts package.  (Only a Pre-Depends is strong enough to 
  ensure that the conffiles are taken over without an orphanic hiatus.)
  Strictly speaking we can drop this dependency now since everyone is
  either installing anew or else has upgraded to sarge; and Debian does
  not support skip upgrades.  However, I don't see any harm in keeping
  this dependency around until after etch releases.  But then it should
  go away.
* initscripts Depends on mount >= 2.11x-1 because that's when swapon's
  "-e" option was added.  Sarge satisfies this requirement so this 
  dependency could be dropped.  We can drop it after etch releases;
  then both stable and oldstable will satisfy the requirement.
* initscripts needs to Depend on debianutils >= 2.12.0 until etch has
  been released so that which can be assumed to be in /bin (rather than
  in /usr/bin, as it was before, including in 2.8.4 in sarge)
* initscripts Conflicts with and Replaces mdutils which was last seen in
  potato.  Can disappear after etch.
* initscripts Conflicts with sysvinit (<< 2.86.ds1-12) because earlier
  versions of bootlogd didn't have the -c option which the bootlogd
  initscripts now uses

Questionable:
* initscripts Replaces various libc packages for reasons described here:
  http://lists.debian.org/debian-hurd/2004/06/msg00048.html.
  Anyone know how long this dependency needs to be carried?
* sysv-rc (current) Conflicts with and Replaces file-rc.  file-rc (0.8.7)
  Replaces: sysv-rc but does not Conflict with it.  I am not sure that
  sysv-rc needs to Replace: file-rc.  Isn't Conflicting sufficient?
  And why doesn't file-rc Conflict with sysv-rc?  Strange.

Possible future:
* If the mtab initscript is ever changed so that it updates the mtab file
  without rerunning mountdevsubfs.sh then initscripts should be made to
  Conflict with udev << 0.080-1.  (The latter versions of udev put the
  udev initscript at S04, _after_ S04mountdevsubfs.sh, and the script
  unmounts /dev/pts and /dev/shm.)


Speed and compatibility
-----------------------
People running Debian on low-memory systems say:
* Use built-ins
* Avoid fork-and-exec, pipelines, $()
* Reduce the number of commands within pipelines
* Avoid unnecessary code
* Avoid commands that don't work the same way in BusyBox:
  'nice', 'find', 'mount', 'umount', 'init', 'halt', 'shutdown', 
  'syslogd', 'klogd', 'hwclock', 'cron', 'anacron', 'crontab'.

Regenerate /etc/default/rcS?
----------------------------
The current /etc/default/rcS template just refers the admin to rcS(5).
This way we have only one set of docs to maintain, and we don't have
to worry about out-of-date comments in /etc/default/rcS.

I wonder if we should strip comments out of existing /etc/default/rcS
files, leaving behind only the reference to rcS(5).

