[Pkg-sysvinit-devel] [LCFC] templates://sysvinit/{sysv-rc.templates}

[Justin B Rye]

Petter Reinholdtsen wrote:
> [Christian Perrier]
>> This is the last call for comments for the review of debconf
>> templates for sysvinit.
> 
> I am unsure if it is a good idea to move all the arguments for
> migrating to the README.  In my experience, very few take the time to
> read more information, and I believe it is important to motivate
> people to do the migration when they get the question.
> 
> On the other hand there were too much information there, so perhaps
> some of the arguments should be moved to the README while the most
> convicing ones are kept in the debconf template?

The argument that convinced me was the one about enabling
concurrency.  I don't know how much it really improved my booting
speed (it was probably switching to dash that had the most effect),
but CONCURRENCY=shell got all the credit because it had the most
visible impact.

Faster booting may not be the only benefit users get from answering
"yes", but many of the other arguments in favour of dependency-based
boot sequencing are really advantages that _Debian_ gets from having
a more flexible and resilient init framework.  They have trickle-down
benefits, especially for testing/unstable users, but they're a lot
more indirect.  People who have tweaked their boot sequence (for
instance to support non-Debian-packaged services) may also get some
of these advantages in the long term, but in the short term the
switch is likely to give them a headache.

How about if we boiled down the reasons to something like this:

  Template: sysv-rc/convert-legacy         
  Type: boolean         
  Default: true         
  Description: Migrate legacy boot sequencing to dependency-based sequencing?
   The boot system is prepared to migrate to dependency-based sequencing.
   This is an irreversible step, but one that is recommended: it allows
   the boot process to be optimized for speed and efficiency, and provides
   a more resilient framework for development.
   .
   A full rationale is detailed in /usr/share/doc/sysvinit/README.Debian.gz.
   If you choose not to migrate now, you can do so later by running 
   "dpkg-reconfigure sysv-rc".         

Then in the README perhaps it would be a good idea to separate the
user-oriented and developer-oriented advantages, since only the
former are really relevant to admins trying to decide whether to
migrate.  Here's another attempt at a rewrite:

  Migrating to dependency-based boot sequencing
  ---------------------------------------------

  Migrating to the dependency-based system of boot sequencing (using LSB
  headers) is non-reversible, and renders obsolete the legacy system of
  static sequence numbers. Please note that any boot sequence changes made
  locally will be lost in the migration, and must be reimplemented in
  terms of dependencies. However, the new system is recommended for
  several reasons.
  * initscripts can be made to run more efficiently via parallelized
    execution strategies (see $POINTER_TO_ENTICING_BOOTCHARTS);
  * boot and shutdown ordering is calculated on the basis of the
    dependency information declared within each init.d script, ensuring
    that the sequence is optimized for the set of packages installed;
  * problems introduced by new or upgraded packages can be detected and
    averted - the boot sequence is only modified if it is safe to do so.

  It can also bring benefits for Debian package development, and for
  admins maintaining local software, since it eliminates the difficulty of
  fitting an initscript into the boot sequence between existing services
  with adjacent sequence numbers.
  
  It is also a step in the direction of boot systems better suited to the
  asynchronous nature of the Linux-2.6 kernel boot process.

That last selling-point might deserve to be moved up the list, but
I'd need some help coming up with a way to phrase it - I'm still
using a lot of antique non-hotpluggable hardware here!

By the way, did anybody ever find out why insserv is called insserv?
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package