Move alternative init systems to avoid renumbering

While keeping all the init-related material together would be nice,
it causes section renumbering, which causes other problems.  Move it
to the bottom of that chapter.  We'll fix this when we rewrite all of
Policy and reorder everything.

diff --git a/policy.sgml b/policy.sgml
index 3a2e7e1599364c3c4d6b74f72136deabb22263ac..43926534da730cac53b3f8dcd6ae16b0e9f1f441 100644 (file)
--- a/policy.sgml
+++ b/policy.sgml
@@ -7866,74 +7866,6 @@ Reloading <var>description</var> configuration...done.
        </p>
       </sect>
 
-      <sect id="alternateinit">
-        <heading>Alternate init systems</heading>
-        <p>
-          A number of other init systems are available now in Debian that
-          can be used in place of <package>sysvinit</package>.  Alternative
-          init implementations must support running SysV init scripts as
-          described at <ref id="sysvinit"> for compatibility.
-        </p>
-        <p>
-          Packages may integrate with these replacement init systems by
-          providing implementation-specific configuration information about
-          how and when to start a service or in what order to run certain
-          tasks at boot time.  However, any package integrating with other
-          init systems must also be backwards-compatible with
-          <package>sysvinit</package> by providing a SysV-style init script
-          with the same name as and equivalent functionality to any
-          init-specific job, as this is the only start-up configuration
-          method guaranteed to be supported by all init implementations.  An
-          exception to this rule is scripts or jobs provided by the init
-          implementation itself; such jobs may be required for an
-          implementation-specific equivalent of the <file>/etc/rcS.d/</file>
-          scripts and may not have a one-to-one correspondence with the init
-          scripts.
-        </p>
-        <sect1 id="upstart">
-          <heading>Event-based boot with upstart</heading>
-
-         <p>
-            Packages may integrate with the <prgn>upstart</prgn> event-based
-            boot system by installing job files in the
-            <file>/etc/init</file> directory.  SysV init scripts for which
-            an equivalent upstart job is available must query the output of
-            the command <prgn>initctl version</prgn> for the string
-            <tt>upstart</tt> and avoid running in favor of the native
-            upstart job, using a test such as this:
-           <example compact="compact">
-if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
-then
-       exit 1
-fi
-           </example>
-          </p>
-          <p>
-            Because packages shipping upstart jobs may be installed on
-            systems that are not using upstart, maintainer scripts must
-            still use the common <prgn>update-rc.d</prgn> and
-            <prgn>invoke-rc.d</prgn> interfaces for configuring runlevels
-            and for starting and stopping services.  These maintainer
-            scripts must not call the upstart <prgn>start</prgn>,
-            <prgn>restart</prgn>, <prgn>reload</prgn>, or <prgn>stop</prgn>
-            interfaces directly.  Instead, implementations of
-            <prgn>invoke-rc.d</prgn> must detect when upstart is running and
-            when an upstart job with the same name as an init script is
-            present, and perform the requested action using the upstart job
-            instead of the init script.
-          </p>
-          <p>
-            Dependency-based boot managers for SysV init scripts, such as
-            <prgn>startpar</prgn>, may avoid running a given init script
-            entirely when an equivalent upstart job is present, to avoid
-            unnecessary forking of no-op init scripts.  In this case, the
-            boot manager should integrate with upstart to detect when the
-            upstart job in question is started or stopped to know when the
-            dependency has been satisfied.
-          </p>
-         </sect1>
-      </sect>
-
       <sect id="cron-jobs">
        <heading>Cron jobs</heading>
 
@@ -8346,6 +8278,74 @@ exec /usr/lib/foo/foo "$@"
        </p>
       </sect>
 
+      <sect id="alternateinit">
+        <heading>Alternate init systems</heading>
+        <p>
+          A number of other init systems are available now in Debian that
+          can be used in place of <package>sysvinit</package>.  Alternative
+          init implementations must support running SysV init scripts as
+          described at <ref id="sysvinit"> for compatibility.
+        </p>
+        <p>
+          Packages may integrate with these replacement init systems by
+          providing implementation-specific configuration information about
+          how and when to start a service or in what order to run certain
+          tasks at boot time.  However, any package integrating with other
+          init systems must also be backwards-compatible with
+          <package>sysvinit</package> by providing a SysV-style init script
+          with the same name as and equivalent functionality to any
+          init-specific job, as this is the only start-up configuration
+          method guaranteed to be supported by all init implementations.  An
+          exception to this rule is scripts or jobs provided by the init
+          implementation itself; such jobs may be required for an
+          implementation-specific equivalent of the <file>/etc/rcS.d/</file>
+          scripts and may not have a one-to-one correspondence with the init
+          scripts.
+        </p>
+        <sect1 id="upstart">
+          <heading>Event-based boot with upstart</heading>
+
+         <p>
+            Packages may integrate with the <prgn>upstart</prgn> event-based
+            boot system by installing job files in the
+            <file>/etc/init</file> directory.  SysV init scripts for which
+            an equivalent upstart job is available must query the output of
+            the command <prgn>initctl version</prgn> for the string
+            <tt>upstart</tt> and avoid running in favor of the native
+            upstart job, using a test such as this:
+           <example compact="compact">
+if [ "$1" = start ] && which initctl >/dev/null && initctl version | grep -q upstart
+then
+       exit 1
+fi
+           </example>
+          </p>
+          <p>
+            Because packages shipping upstart jobs may be installed on
+            systems that are not using upstart, maintainer scripts must
+            still use the common <prgn>update-rc.d</prgn> and
+            <prgn>invoke-rc.d</prgn> interfaces for configuring runlevels
+            and for starting and stopping services.  These maintainer
+            scripts must not call the upstart <prgn>start</prgn>,
+            <prgn>restart</prgn>, <prgn>reload</prgn>, or <prgn>stop</prgn>
+            interfaces directly.  Instead, implementations of
+            <prgn>invoke-rc.d</prgn> must detect when upstart is running and
+            when an upstart job with the same name as an init script is
+            present, and perform the requested action using the upstart job
+            instead of the init script.
+          </p>
+          <p>
+            Dependency-based boot managers for SysV init scripts, such as
+            <prgn>startpar</prgn>, may avoid running a given init script
+            entirely when an equivalent upstart job is present, to avoid
+            unnecessary forking of no-op init scripts.  In this case, the
+            boot manager should integrate with upstart to detect when the
+            upstart job in question is started or stopped to know when the
+            dependency has been satisfied.
+          </p>
+         </sect1>
+      </sect>
+
     </chapt>