Document Debconf's escape capability.

[debian/debian-policy.git] / policy.sgml

diff --git a/policy.sgml b/policy.sgml
index 0965b76bf89cb2fcbaaa62e6671016458f042e62..d81891c7c5f2b52af5c26cebabde59dc4b2d9014 100644 (file)
--- a/policy.sgml
+++ b/policy.sgml
@@ -1729,7 +1729,7 @@ zope.
 /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
              </example>
              Then all of the bug numbers listed will be closed by the
 /closes:\s*(?:bug)?\#?\s?\d+(?:,\s*(?:bug)?\#?\s?\d+)*/i
              </example>
              Then all of the bug numbers listed will be closed by the

-             archive maintenance script (<prgn>katie</prgn>) using the
+             archive maintenance software (<prgn>dak</prgn>) using the

              <var>version</var> of the changelog entry.
          </footnote>
          This information is conveyed via the <tt>Closes</tt> field
              <var>version</var> of the changelog entry.
          </footnote>
          This information is conveyed via the <tt>Closes</tt> field


@@ -1988,51 +1988,33 @@ zope.
              </p>
            </item>
 
              </p>
            </item>
 

-           <tag><tt>build-arch</tt> (optional),
-                <tt>build-indep</tt> (optional)
+           <tag><tt>build-arch</tt> (required),
+                <tt>build-indep</tt> (required)

            </tag>
            <item>
              <p>
            </tag>
            <item>
              <p>

-               A package may also provide one or both of the targets
-               <tt>build-arch</tt> and <tt>build-indep</tt>.
-               The <tt>build-arch</tt> target, if provided, should
+               The <tt>build-arch</tt> target must

                perform all the configuration and compilation required for
                producing all architecture-dependant binary packages
                (those packages for which the body of the
                <tt>Architecture</tt> field in <tt>debian/control</tt> is
                not <tt>all</tt>).  Similarly, the <tt>build-indep</tt>
                perform all the configuration and compilation required for
                producing all architecture-dependant binary packages
                (those packages for which the body of the
                <tt>Architecture</tt> field in <tt>debian/control</tt> is
                not <tt>all</tt>).  Similarly, the <tt>build-indep</tt>

-               target, if provided, should perform all the configuration
+               target must perform all the configuration

                and compilation required for producing all
                architecture-independent binary packages (those packages
                for which the body of the <tt>Architecture</tt> field
                in <tt>debian/control</tt> is <tt>all</tt>).
                and compilation required for producing all
                architecture-independent binary packages (those packages
                for which the body of the <tt>Architecture</tt> field
                in <tt>debian/control</tt> is <tt>all</tt>).

-             </p>
-
-             <p>
-               If <tt>build-arch</tt> or <tt>build-indep</tt> targets are
-               provided in the rules file, the <tt>build</tt> target
+               The <tt>build</tt> target

                should either depend on those targets or take the same
                actions as invoking those targets would perform.<footnote>
                should either depend on those targets or take the same
                actions as invoking those targets would perform.<footnote>

-                 The intent of this split is so that binary-only builds
-                 need not install the dependencies required for
-                 the <tt>build-indep</tt> target.  However, this is not
-                 yet used in practice since <tt>dpkg-buildpackage
-                 -B</tt>, and therefore the autobuilders,
-                 invoke <tt>build</tt> rather than <tt>build-arch</tt>
-                 due to the difficulties in determining whether the
-                 optional <tt>build-arch</tt> target exists.
+                 This split allows binary-only builds to not install the
+                 dependencies required for the <tt>build-indep</tt>
+                 target and skip any resource-intensive build tasks that
+                 are only required when building architecture-independent
+                 binary packages.

                </footnote>
              </p>
 
                </footnote>
              </p>
 

-             <p>
-               If one or both of the targets <tt>build-arch</tt> and
-               <tt>build-indep</tt> are not provided, then invoking
-               <file>debian/rules</file> with one of the not-provided
-               targets as arguments should produce a exit status code
-               of 2.  Usually this is provided automatically by make
-               if the target is missing.
-             </p>
-

              <p>
                The <tt>build-arch</tt> and <tt>build-indep</tt> targets
                must not do anything that might require root privilege.
              <p>
                The <tt>build-arch</tt> and <tt>build-indep</tt> targets
                must not do anything that might require root privilege.


@@ -2667,7 +2649,6 @@ Package: libc6
            <item><qref id="f-Source"><tt>Source</tt></qref> (mandatory)</item>
            <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (mandatory)</item>
            <item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>
            <item><qref id="f-Source"><tt>Source</tt></qref> (mandatory)</item>
            <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (mandatory)</item>
            <item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>

-           <item><qref id="f-DM-Upload-Allowed"><tt>DM-Upload-Allowed</tt></qref></item>

            <item><qref id="f-Section"><tt>Section</tt></qref> (recommended)</item>
            <item><qref id="f-Priority"><tt>Priority</tt></qref> (recommended)</item>
            <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
            <item><qref id="f-Section"><tt>Section</tt></qref> (recommended)</item>
            <item><qref id="f-Priority"><tt>Priority</tt></qref> (recommended)</item>
            <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>


@@ -2690,6 +2671,7 @@ Package: libc6
            <item><qref id="f-Description"><tt>Description</tt></qref> (mandatory)</item>
            <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
            <item><qref id="built-using"><tt>Built-Using</tt></qref></item>
            <item><qref id="f-Description"><tt>Description</tt></qref> (mandatory)</item>
            <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
            <item><qref id="built-using"><tt>Built-Using</tt></qref></item>

+           <item><qref id="f-Package-Type"><tt>Package-Type</tt></qref></item>

          </list>
        </p>
 
          </list>
        </p>
 


@@ -2766,13 +2748,13 @@ Package: libc6
          <item><qref id="f-Version"><tt>Version</tt></qref> (mandatory)</item>
          <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (mandatory)</item>
          <item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>
          <item><qref id="f-Version"><tt>Version</tt></qref> (mandatory)</item>
          <item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (mandatory)</item>
          <item><qref id="f-Uploaders"><tt>Uploaders</tt></qref></item>

-         <item><qref id="f-DM-Upload-Allowed"><tt>DM-Upload-Allowed</tt></qref></item>

          <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
          <item><qref id="f-VCS-fields"><tt>Vcs-Browser</tt>, <tt>Vcs-Git</tt>, et al.</qref></item>
          <item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommended)</item>
          <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
          <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
          <item><qref id="f-VCS-fields"><tt>Vcs-Browser</tt>, <tt>Vcs-Git</tt>, et al.</qref></item>
          <item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommended)</item>
          <item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>

+         <item><qref id="f-Package-List"><tt>Package-List</tt></qref> (recommended)</item>

          <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>
          <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>

-             and <tt>Checksums-Sha256</tt></qref> (recommended)</item>
+             and <tt>Checksums-Sha256</tt></qref> (mandatory)</item>

          <item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
        </list>
        </p>
          <item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
        </list>
        </p>


@@ -2825,7 +2807,7 @@ Package: libc6
            <item><qref id="f-Closes"><tt>Closes</tt></qref></item>
            <item><qref id="f-Changes"><tt>Changes</tt></qref> (mandatory)</item>
            <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>
            <item><qref id="f-Closes"><tt>Closes</tt></qref></item>
            <item><qref id="f-Changes"><tt>Changes</tt></qref> (mandatory)</item>
            <item><qref id="f-Checksums"><tt>Checksums-Sha1</tt>

-               and <tt>Checksums-Sha256</tt></qref> (recommended)</item>
+               and <tt>Checksums-Sha256</tt></qref> (mandatory)</item>

            <item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
          </list>
        </p>
            <item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
          </list>
        </p>


@@ -3759,28 +3741,19 @@ Checksums-Sha256:
          </p>
 
          <p>
          </p>
 
          <p>

-           In the <file>.dsc</file> file, these fields should list all
+           In the <file>.dsc</file> file, these fields list all

            files that make up the source package.  In
            files that make up the source package.  In

-           the <file>.changes</file> file, these fields should list all
+           the <file>.changes</file> file, these fields list all

            files being uploaded.  The list of files in these fields
            must match the list of files in the <tt>Files</tt> field.
          </p>
        </sect1>
 
            files being uploaded.  The list of files in these fields
            must match the list of files in the <tt>Files</tt> field.
          </p>
        </sect1>
 

-       <sect1 id="f-DM-Upload-Allowed">
+       <sect1>

          <heading><tt>DM-Upload-Allowed</tt></heading>
 
          <p>
          <heading><tt>DM-Upload-Allowed</tt></heading>
 
          <p>

-           Indicates that Debian Maintainers may upload this package to
-           the Debian archive.  The only valid value is <tt>yes</tt>.  If
-           the field <tt>DM-Upload-Allowed: yes</tt> is present in the
-           source section of the source control file of the most recent
-           version of a package in unstable or experimental, the Debian
-           archive will accept uploads of this package signed with a key
-           in the Debian Maintainer keyring.  See the General
-           Resolution <url id="http://www.debian.org/vote/2007/vote_003"
-           name="Endorse the concept of Debian Maintainers"> for more
-           details.
+           Obsolete, see <qref id="f-DM-Upload-Allowed">below</qref>.

          </p>
        </sect1>
 
          </p>
        </sect1>
 


@@ -3830,6 +3803,34 @@ Checksums-Sha256:
            </taglist>
          </p>
        </sect1>
            </taglist>
          </p>
        </sect1>

+
+       <sect1 id="f-Package-List">
+         <heading><tt>Package-List</tt></heading>
+
+         <p>
+           Multiline field listing all the packages that can be built from
+           the source package, considering every architecture.  The first line
+           of the field value is empty.  Each one of the next lines describes
+           one binary package, by listing its name, type, section and priority
+           separated by spaces.  Fifth and subsequent space-separated items
+           may be present and parsers must allow them.  See the
+           <qref id="f-Package-Type">Package-Type</qref> field for a list of
+           package types.
+         </p>
+       </sect1>
+
+       <sect1 id="f-Package-Type">
+         <heading><tt>Package-Type</tt></heading>
+
+         <p>
+           Simple field containing a word indicating the type of package:
+           <tt>deb</tt> for binary packages and <tt>udeb</tt> for micro binary
+           packages.  Other types not defined here may be indicated.  In
+           source package control files, the <tt>Package-Type</tt> field
+           should be omitted instead of giving it a value of <tt>deb</tt>, as
+           this value is assumed for paragraphs lacking this field.
+         </p>
+       </sect1>

       </sect>
 
       <sect>
       </sect>
 
       <sect>


@@ -3876,6 +3877,28 @@ Checksums-Sha256:
 
       </sect>
 
 
       </sect>
 

+      <sect id="obsolete-control-data-fields">
+       <heading>Obsolete fields</heading>
+
+       <p>
+         The following fields have been obsoleted and may be found in packages
+         conforming with previous versions of the Policy.
+       </p>
+
+       <sect1 id="f-DM-Upload-Allowed">
+         <heading><tt>DM-Upload-Allowed</tt></heading>
+
+         <p>
+           Indicates that Debian Maintainers may upload this package to
+           the Debian archive.  The only valid value is <tt>yes</tt>.  This
+           field was used to regulate uploads by Debian Maintainers, See the
+           General Resolution <url id="http://www.debian.org/vote/2007/vote_003"
+           name="Endorse the concept of Debian Maintainers"> for more details.
+         </p>
+       </sect1>
+
+      </sect>
+

     </chapt>
 
 
     </chapt>
 
 


@@ -5646,7 +5669,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
        <p>
          To determine the <var>soversion</var>, look at
          the <tt>SONAME</tt> of the library, stored in the
        <p>
          To determine the <var>soversion</var>, look at
          the <tt>SONAME</tt> of the library, stored in the

-         ELF <tt>SONAME</tt> attribute.  it is usually of the
+         ELF <tt>SONAME</tt> attribute.  It is usually of the

          form <tt><var>name</var>.so.<var>major-version</var></tt> (for
          example, <tt>libz.so.1</tt>).  The version part is the part
          which comes after <tt>.so.</tt>, so in that example it
          form <tt><var>name</var>.so.<var>major-version</var></tt> (for
          example, <tt>libz.so.1</tt>).  The version part is the part
          which comes after <tt>.so.</tt>, so in that example it


@@ -5978,11 +6001,11 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
          whether new library interfaces are available and can be called).
          To allow these dependencies to be constructed, shared libraries
          must provide either a <file>symbols</file> file or
          whether new library interfaces are available and can be called).
          To allow these dependencies to be constructed, shared libraries
          must provide either a <file>symbols</file> file or

-         a <file>shlibs</file> file, which provides information on the
+         a <file>shlibs</file> file.  These provide information on the

          package dependencies required to ensure the presence of
          interfaces provided by this library.  Any package with binaries
          package dependencies required to ensure the presence of
          interfaces provided by this library.  Any package with binaries

-         or libraries linking to a shared library must use these files
-         to determine the required dependencies when it is built.  Other
+         or libraries linking to a shared library must use these files to
+         determine the required dependencies when it is built.  Other

          packages which use a shared library (for example using
          <tt>dlopen()</tt>) should compute appropriate dependencies
          using these files at build time as well.
          packages which use a shared library (for example using
          <tt>dlopen()</tt>) should compute appropriate dependencies
          using these files at build time as well.


@@ -5990,21 +6013,25 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
 
        <p>
          The two mechanisms differ in the degree of detail that they
 
        <p>
          The two mechanisms differ in the degree of detail that they

-         provide.  A <file>symbols</file> file documents for each symbol
-         exported by a library the minimal version of the package any
-         binary using this symbol will need, which is typically the
-         version of the package in which the symbol was introduced.
-         This permits detailed analysis of the symbols used by a
+         provide.  A <file>symbols</file> file documents, for each symbol
+         exported by a library, the minimal version of the package any
+         binary using this symbol will need.  This is typically the
+         version of the package in which the symbol was introduced.  This
+         information permits detailed analysis of the symbols used by a

          particular package and construction of an accurate dependency,
          but it requires the package maintainer to track more information
          particular package and construction of an accurate dependency,
          but it requires the package maintainer to track more information

-         about the shared library.  A <file>shlibs</file> file, in
-         contrast, only documents the last time the library ABI changed
-         in any way.  It only provides information about the library as a
-         whole, not individual symbols.  When a package is built using a
-         shared library with only a <file>shlibs</file> file, the generated
-         dependency will require a version of the shared library equal to
-         or newer than the version of the last ABI change.  This
-         generates unnecessarily restrictive dependencies compared
+         about the shared library.
+       </p>
+
+       <p>
+         A <file>shlibs</file> file, in contrast, only documents the last
+         time the library ABI changed in any way.  It only provides
+         information about the library as a whole, not individual
+         symbols.  When a package is built using a shared library with
+         only a <file>shlibs</file> file, the generated dependency will
+         require a version of the shared library equal to or newer than
+         the version of the last ABI change.  This generates
+         unnecessarily restrictive dependencies compared

          to <file>symbols</file> files if none of the symbols used by the
          package have changed.  This, in turn, may make upgrades
          needlessly complex and unnecessarily restrict use of the package
          to <file>symbols</file> files if none of the symbols used by the
          package have changed.  This, in turn, may make upgrades
          needlessly complex and unnecessarily restrict use of the package


@@ -6012,12 +6039,15 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
        </p>
 
        <p>
        </p>
 
        <p>

-         <file>shlibs<file> files also have a flawed representation of
+         <file>shlibs</file> files also only support a limited range of

          library SONAMEs, making it difficult to use <file>shlibs</file>
          files in some unusual corner cases.<footnote>
          library SONAMEs, making it difficult to use <file>shlibs</file>
          files in some unusual corner cases.<footnote>

-           libfooN.shlibs says 'libfoo N' instead of the actual SONAME,
-           so if the SONAME doesn't match one of the two expected
-           formats (libfoo-N.so or libfoo.so.N) it can't be represented.
+           A <file>shlibs</file> file represents an SONAME as a library
+           name and version number, such as <tt>libfoo VERSION</tt>,
+           instead of recording the actual SONAME.  If the SONAME doesn't
+           match one of the two expected formats
+           (<tt>libfoo-VERSION.so</tt> or <tt>libfoo.so.VERSION</tt>), it
+           cannot be represented.

          </footnote>
        </p>
 
          </footnote>
        </p>
 


@@ -6029,8 +6059,9 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
          maintain.  However, maintaining exhaustive symbols information
          for a C++ library can be quite onerous, so <file>shlibs</file>
          files may be more appropriate for most C++ libraries.  Libraries
          maintain.  However, maintaining exhaustive symbols information
          for a C++ library can be quite onerous, so <file>shlibs</file>
          files may be more appropriate for most C++ libraries.  Libraries

-         with a corresponding udeb must also provide <file>shlibs</file>,
-         since the udeb infrastructure does not use <file>symbols</file>.
+         with a corresponding udeb must also provide
+         a <file>shlibs</file> file, since the udeb infrastructure does
+         not use <file>symbols</file> files.

        </p>
 
        <sect1 id="dpkg-shlibdeps">
        </p>
 
        <sect1 id="dpkg-shlibdeps">


@@ -6089,10 +6120,10 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
            binaries, libraries, or loadable modules.  If you have
            multiple binary packages, you will need to
            call <prgn>dpkg-shlibdeps</prgn> on each one which contains
            binaries, libraries, or loadable modules.  If you have
            multiple binary packages, you will need to
            call <prgn>dpkg-shlibdeps</prgn> on each one which contains

-           compiled libraries or binaries, for example using the
-           <tt>-T</tt> option to the <tt>dpkg</tt> utilities to specify a
-           different <file>substvars</file> file for each binary
-           package.<footnote>
+           compiled libraries or binaries.  For example, you could use
+           the <tt>-T</tt> option to the <tt>dpkg</tt> utilities to
+           specify a different <file>substvars</file> file for each
+           binary package.<footnote>

              Again, <prgn>dh_shlibdeps</prgn>
              and <prgn>dh_gencontrol</prgn> will handle everything except
              the addition of the variable to the control file for you if
              Again, <prgn>dh_shlibdeps</prgn>
              and <prgn>dh_gencontrol</prgn> will handle everything except
              the addition of the variable to the control file for you if


@@ -6166,7 +6197,18 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
            backward-compatible if any reasonable program or library that
            was linked with the previous version of the shared library
            will still work correctly with the new version of the shared
            backward-compatible if any reasonable program or library that
            was linked with the previous version of the shared library
            will still work correctly with the new version of the shared

-           library.  Adding new symbols to the shared library is a
+           library.<footnote>
+             An example of an "unreasonable" program is one that uses
+             library interfaces that are documented as internal and
+             unsupported.  If the only programs or libraries affected by
+             a change are "unreasonable" ones, other techniques, such as
+             declaring <tt>Breaks</tt> relationships with affected
+             packages or treating their usage of the library as bugs in
+             those packages, may be appropriate instead of changing the
+             SONAME.  However, the default approach is to change the
+             SONAME for any change to the ABI that could break a program.
+           </footnote>
+           Adding new symbols to the shared library is a

            backward-compatible change.  Removing symbols from the shared
            library is not.  Changing the behavior of a symbol may or may
            not be backward-compatible depending on the change; for
            backward-compatible change.  Removing symbols from the shared
            library is not.  Changing the behavior of a symbol may or may
            not be backward-compatible depending on the change; for


@@ -6219,9 +6261,9 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
          </p>
 
          <p>
          </p>
 
          <p>

-           A common example of when a change to the is required is a
-           function that takes an enum or struct argument that controls
-           what the function does.  For example:
+           A common example of when a change to the dependency version
+           is required is a function that takes an enum or struct
+           argument that controls what the function does.  For example:

            <example>
              enum library_op { OP_FOO, OP_BAR };
              int library_do_operation(enum library_op);
            <example>
              enum library_op { OP_FOO, OP_BAR };
              int library_do_operation(enum library_op);


@@ -6470,8 +6512,9 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
              recent version of the shared library that changed the
              behavior of that symbol, whether by adding it, changing its
              function signature (the parameters, their types, or the
              recent version of the shared library that changed the
              behavior of that symbol, whether by adding it, changing its
              function signature (the parameters, their types, or the

-             return type), or its behavior in a way that is visible to a
-             caller.  <var>id-of-dependency-template</var> is an optional
+             return type), or changing its behavior in a way that is
+             visible to a caller.
+             <var>id-of-dependency-template</var> is an optional

              field that references
              an <var>alternative-dependency-template</var>; see below for
              a full description.
              field that references
              an <var>alternative-dependency-template</var>; see below for
              a full description.


@@ -6621,7 +6664,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
          <heading>The <tt>shlibs</tt> system</heading>
 
          <p>
          <heading>The <tt>shlibs</tt> system</heading>
 
          <p>

-           The <tt>shlibs</tt> system is an simpler alternative to
+           The <tt>shlibs</tt> system is a simpler alternative to

            the <tt>symbols</tt> system for declaring dependencies for
            shared libraries.  It may be more appropriate for C++
            libraries and other cases where tracking individual symbols is
            the <tt>symbols</tt> system for declaring dependencies for
            shared libraries.  It may be more appropriate for C++
            libraries and other cases where tracking individual symbols is


@@ -6779,7 +6822,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
              library was in version <tt>1:1.2.3.3.dfsg-1</tt>, then
              the <tt>shlibs</tt> entry for this library could say:
              <example compact="compact">
              library was in version <tt>1:1.2.3.3.dfsg-1</tt>, then
              the <tt>shlibs</tt> entry for this library could say:
              <example compact="compact">

-               libz 1 zlib1g (>= 1:1.2.3.3.dfsg-1)
+               libz 1 zlib1g (>= 1:1.2.3.3.dfsg)

              </example>
              This version restriction must be new enough that any binary
              built against the current version of the library will work
              </example>
              This version restriction must be new enough that any binary
              built against the current version of the library will work


@@ -6791,7 +6834,7 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
              As zlib1g also provides a udeb containing the shared
              library, there would also be a second line:
              <example compact="compact">
              As zlib1g also provides a udeb containing the shared
              library, there would also be a second line:
              <example compact="compact">

-               udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg-1)
+               udeb: libz 1 zlib1g-udeb (>= 1:1.2.3.3.dfsg)

              </example>
            </p>
          </sect2>
              </example>
            </p>
          </sect2>


@@ -6942,6 +6985,12 @@ Built-Using: grub2 (= 1.99-9), loadlin (= 1.6e-1)
                  in <file>/run</file> should be stored on a temporary
                  file system.
                </p>
                  in <file>/run</file> should be stored on a temporary
                  file system.
                </p>

+               <p>
+                 Packages must not assume the <file>/run</file>
+                 directory exists or is usable without a dependency
+                 on <tt>initscripts (>= 2.88dsf-13.3)</tt> until the
+                 stable release of Debian supports <file>/run</file>.
+               </p>

              </item>
               <item>
                 <p>
              </item>
               <item>
                 <p>


@@ -8030,33 +8079,28 @@ Reloading <var>description</var> configuration...done.
        </p>
 
        <p>
        </p>
 
        <p>

-         Packages which provide the ability to view/show/play,
-         compose, edit or print MIME types should register themselves
-         as such following the current MIME support policy.
+         Packages which provide programs to view/show/play, compose, edit or
+         print MIME types should register them as such by placing a file in
+         <manref name="mailcap" section="5"> format (RFC 1524) in the directory
+         <file>/usr/lib/mime/packages/</file>.  The file name should be the
+         binary package's name.

        </p>
 
        <p>
          The <package>mime-support</package> package provides the
        </p>
 
        <p>
          The <package>mime-support</package> package provides the

-         <prgn>update-mime</prgn> program which allows packages to
-         register programs that can show, compose, edit or print
-         MIME types.
-       </p>
-
-       <p>
-         Packages containing such programs must register them
-         with <prgn>update-mime</prgn> as documented in <manref
-         name="update-mime" section="8">. They should <em>not</em> depend
-         on, recommend, or suggest <prgn>mime-support</prgn>. Instead,
-         they should just put something like the following in the
-         <tt>postinst</tt> and <tt>postrm</tt> scripts:
-
-         <example>
-  if [ -x /usr/sbin/update-mime ]; then
-      update-mime
-  fi
-         </example>
+         <prgn>update-mime</prgn> program, which integrates these
+         registrations in the <file>/etc/mailcap</file> file, using dpkg
+         triggers<footnote>
+           Creating, modifying or removing a file in
+           <file>/usr/lib/mime/packages/</file> using maintainer scripts will
+           not activate the trigger.  In that case, it can be done by calling
+           <tt>dpkg-trigger --no-await /usr/lib/mime/packages</tt> from
+           the maintainer script after creating, modifying, or removing
+           the file.
+         </footnote>.
+         Packages using this facility <em>should not</em> depend on,
+         recommend, or suggest <prgn>mime-support</prgn>.

        </p>
        </p>

-

       </sect>
 
       <sect>
       </sect>
 
       <sect>


@@ -8270,6 +8314,74 @@ exec /usr/lib/foo/foo "$@"
        </p>
       </sect>
 
        </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>
 
 
     </chapt>
 
 


@@ -10755,12 +10867,6 @@ END-INFO-DIR-ENTRY
        <prgn>dpkg</prgn>, <prgn>dselect</prgn> et al. and the way
        they interact with packages.</p>
 
        <prgn>dpkg</prgn>, <prgn>dselect</prgn> et al. and the way
        they interact with packages.</p>
 

-      <p>
-       It also documents the interaction between
-       <prgn>dselect</prgn>'s core and the access method scripts it
-       uses to actually install the selected packages, and describes
-       how to create a new access method.</p>
-

       <p>
        This manual does not go into detail about the options and
        usage of the package building and installation tools.  It
       <p>
        This manual does not go into detail about the options and
        usage of the package building and installation tools.  It