* Finished chapter 11

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

<!doctype debiandoc system [
<!-- include version information so we don't have to hard code it
     within the document -->
<!entity % versiondata SYSTEM "version.ent"> %versiondata;
]>
<debiandoc>
  <!--
  Debian GNU/Linux Policy Manual.
  Copyright (C)1996,1997,1998 Ian Jackson and Christian Schwarz;
  released under the terms of the GNU
  General Public License, version 2 or (at your option) any later.
  Initial version 1996, Ian Jackson, ijackson@gnu.ai.mit.edu
  Revised November 27, 1996, David A. Morris, bweaver@debian.org
  New sections March 15, 1997, Christian Schwarz, schwarz@debian.org
  Reworked/Restructured April-July 1997, Christian Schwarz, schwarz@debian.org
  Maintainer since 1997, Christian Schwarz, schwarz@debian.org
  Christoph Lameter contributed the "Web Standard"
  The debian-policy mailing list has taken responsibility for the
  contents of this document since September 1998, with the package
  maintainers responsible for packaging administrivia only.
  -->

  <book>
    <titlepag>
      <title>Debian Policy Manual</title>
      <author>
        <name>Ian Jackson </name>
        <email>ijackson@gnu.ai.mit.edu</email>
      </author>
      <author>
        <name>Christian Schwarz</name>
        <email>schwarz@debian.org</email>
      </author>
      <author>
        <name>revised: David A. Morris</name>
        <email>bweaver@debian.org</email>
      </author>
      <author>
        <name>The Debian Policy mailing List</name>
        <email>debian-policy@lists.debian.org</email>
      </author>
      <version>version &version;, &date;</version>

      <abstract>
        This manual describes the policy requirements for the Debian
        GNU/Linux distribution. This includes the structure and
        contents of the Debian archive and several design issues of the
        operating system, as well as technical requirements that each
        package must satisfy to be included in the distribution. The
        policy package itself is maintained by a group of maintainers
        that have no editorial powers. At the moment, the list of
        maintainers is:
        <enumlist>
          <item>
            <p>Julian Gilbey <email>jdg@debian.org</email></p>
          </item>
          <item>
            <p>Manoj Srivastava <email>srivasta@debian.org</email></p>
          </item>
        </enumlist>
      </abstract>


      <copyright>
        <copyrightsummary>
          Copyright &copy;1996,1997,1998 Ian Jackson
          and Christian Schwarz.
        </copyrightsummary>
        <p>
          This manual is free software; you may redistribute it and/or
          modify it under the terms of the GNU General Public License
          as published by the Free Software Foundation; either version
          2, or (at your option) any later version.
        </p>

        <p>
          This is distributed in the hope that it will be useful, but
          <em>without any warranty</em>; without even the implied
          warranty of merchantability or fitness for a particular
          purpose.  See the GNU General Public License for more
          details.
        </p>

        <p>
          A copy of the GNU General Public License is available as
          <tt>/usr/share/common-licenses/GPL</tt> in the Debian GNU/Linux
          distribution or on the World Wide Web at
          <url id="http://www.gnu.org/copyleft/gpl.html"
               name="The GNU General Public Licence">. You can also
          obtain it by writing to the Free Software Foundation, Inc.,
          59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
        </p>
      </copyright>
    </titlepag>

    <toc detail="sect">

    <chapt id="scope">
      <heading>About this manual</heading>
      <sect>
        <heading>Scope</heading>
        <p>
          This manual describes the policy requirements for the Debian
          GNU/Linux distribution. This includes the structure and
          contents of the Debian archive and several design issues of the
          operating system, as well as technical requirements that
          each package must satisfy to be included in the
          distribution.
        </p>


        <p>
          This manual also describes Debian policy as it relates to
          creating Debian packages. It is not a tutorial on how to build
          packages, nor is it exhaustive where it comes to describing
          the behavior of the packaging system. Instead, this manual
          attempts to define the interface to the package management
          system that the developers have to be conversant with.
          <footnote>
            <p>
              Informally, the criteria used for inclusion is that the
              material meet one of the following requirements:
              <taglist compact="compact">
                <tag>Standard interfaces</tag>
                <item>
                  <p>
                    The material presented represents an interface to
                    the packaging system that is mandated for use, and
                    is used by, a significant number of packages, and
                    therefore should not be changed without peer
                    review. Package maintainers can then rely on this
                    interfaces not changing, and the package
                    management software authors need to ensure
                    compatibility with these interface
                    definitions. (Control file and changelog file
                    formats are examples.)
                  </p>
                </item>
                <tag>Chosen Convention</tag>
                <item>
                  <p>
                    If there are a number of technically viable choices
                    that can be made, but one needs to select one of
                    these options for inter-operability. The version
                    number format is one example.
                  </p>
                </item>
              </taglist>
              Please note that these are not mutually exclusive;
              selected conventions often become parts of standard
              interfaces.
            </p>
          </footnote>
        </p>

        <p>
          The footnotes present in this manual are
          merely informative, and are not part of Debian policy itself.
        </p>


        <p>
          In this manual, the words <em>must</em>, <em>should</em> and
          <em>may</em>, and the adjectives <em>required</em>,
          <em>recommended</em> and <em>optional</em>, are used to
          distinguish the significance of the various guidelines in
          this policy document. Packages that do not conform to the
          guidelines denoted by <em>must</em> (or <em>required</em>)
          will generally not be considered acceptable for the Debian
          distribution. Non-conformance with guidelines denoted by
          <em>should</em> (or <em>recommended</em>) will generally be
          considered a bug, but will not necessarily render a package
          unsuitable for distribution. Guidelines denoted by
          <em>may</em> (or <em>optional</em>) are truly optional and
          adherence is left to the maintainer's discretion.
        </p>
        <p>
          These classifications are roughly equivalent to the bug
          severities <em>serious</em> (for <em>must</em> or
          <em>required</em> directive violations), <em>minor</em>,
          <em>normal</em> or <em>important</em>
          (for <em>should</em> or <em>recommended</em> directive
          violations) and <em>wishlist</em> (for <em>optional</em>
          items). <footnote>
            <p>Compare RFC 2119.  Note, however, that these words are
          used in a different way in this document.</p>
          </footnote>
        </p>
        <p>
          Much of the information presented in this manual will be
          useful even when building a package which is to be
          distributed in some other way or is intended for local use
          only.
        </p>
      </sect>
      <sect>
        <heading>New versions of this document</heading>
        <p>
          The current version of this document is always accessible
          from the Debian FTP server <ftpsite>ftp.debian.org</ftpsite>
          as
          <ftppath>/debian/doc/package-developer/policy.txt.gz</ftppath>
          (also available from the same directory are several other
          formats: <tt>policy.html.tar.gz</tt>, <tt>policy.pdf.gz</tt>
          and <tt>policy.ps.gz</tt>) or from the <url
          id="http://www.debian.org/doc/debian-policy/" name="Debian
          Policy Manual"> webpage.</p>

        <p>
          In addition, this manual is distributed via the Debian package
          <tt>debian-policy</tt>.
        </p>

        <p>
          The <tt>debian-policy</tt> package also includes the file
          <tt>upgrading-checklist.txt</tt> which indicates policy
          changes between versions of this document.
        </p>
      </sect>
      <sect>
        <heading>Feedback</heading>

        <p>
          As the Debian GNU/Linux system is continuously evolving this
          manual does so too.
        </p>
        <p>
          While the authors of this document have tried hard to avoid
          typos and other errors, these do still occur. If you discover
          an error in this manual or if you want to give any
          comments, suggestions, or criticisms please send an email to
          the Debian Policy List,
          <email>debian-policy@lists.debian.org</email>, or submit a
          bug report against the <tt>debian-policy</tt> package.
        </p>
      </sect>
    </chapt>

    <chapt id="archive">
      <heading>The Debian Archive</heading>
      <p>
        The Debian GNU/Linux system is maintained and distributed as a
        collection of <em>packages</em>. Since there are so many of
        them (currently well over 6000), they are split into
        <em>sections</em> and given <em>priorities</em> to simplify
        the handling of them.
      </p>
      <p>
        The effort of the Debian project is to build a free operating
        system, but not every package we want to make accessible is
        <em>free</em> in our sense (see the Debian Free Software
        Guidelines, below), or may be imported/exported without
        restrictions. Thus, the archive is split into the sections
        <em>main</em>, <em>non-free</em>, <em>contrib</em>,
        <em>non-US/main</em>, <em>non-US/non-free</em>, and
        <em>non-US/contrib</em>.  The sections are explained in detail
        below.
      </p>

      <p>
        The <em>main</em> and the <em>non-US/main</em> sections
        together form the <em>Debian GNU/Linux distribution</em>.
      </p>

      <p>
        Packages in the other sections are not considered to be part
        of the Debian distribution, although we support their use and
        provide infrastructure for them (such as our bug-tracking
        system and mailing lists). This Debian Policy Manual applies
        to these packages as well.</p>

      <sect id="pkgcopyright">
        <heading>Package copyright and sections</heading>
        <p>
          The aims of this section are:

          <list compact="compact">
            <item>
              <p>to allow us to make as much software available as we
                can,</p>
            </item>
            <item>
              <p>to allow us to encourage everyone to write free
              software, and</p>
            </item>
            <item>
              <p>to allow us to make it easy for people to produce
                CD-ROMs of our system without violating any licenses,
                import/export restrictions, or any other laws.</p>
            </item>
          </list>
        </p>
        <sect1>
          <heading>The Debian Free Software Guidelines</heading>
          <p>
            The Debian Free Software Guidelines (DFSG) form our
            definition of `free software'.  These are:
            <taglist>
              <tag>Free Redistribution
              </tag>
              <item>
                <p>
                  The license of a Debian component may not restrict any
                  party from selling or giving away the software as a
                  component of an aggregate software distribution
                  containing programs from several different
                  sources. The license may not require a royalty or
                  other fee for such sale.
                </p>
              </item>
              <tag>Source Code
              </tag>
              <item>
                <p>
                  The program must include source code, and must allow
                  distribution in source code as well as compiled form.
                </p>
              </item>
              <tag>Derived Works
              </tag>
              <item>
                <p>
                  The license must allow modifications and derived
                  works, and must allow them to be distributed under the
                  same terms as the license of the original software.
                </p>
              </item>
              <tag>Integrity of The Author's Source Code
              </tag>
              <item>
                <p>
                  The license may restrict source-code from being
                  distributed in modified form <em>only</em> if the
                  license allows the distribution of ``patch files''
                  with the source code for the purpose of modifying the
                  program at build time. The license must explicitly
                  permit distribution of software built from modified
                  source code. The license may require derived works to
                  carry a different name or version number from the
                  original software.  (This is a compromise. The Debian
                  Project encourages all authors to not restrict any
                  files, source or binary, from being modified.)
                </p>
              </item>
              <tag>No Discrimination Against Persons or Groups
              </tag>
              <item>
                <p>
                  The license must not discriminate against any person
                  or group of persons.
                </p>
              </item>
              <tag>No Discrimination Against Fields of Endeavor
              </tag>
              <item>
                <p>
                  The license must not restrict anyone from making use
                  of the program in a specific field of endeavor. For
                  example, it may not restrict the program from being
                  used in a business, or from being used for genetic
                  research.
                </p>
              </item>
              <tag>Distribution of License
              </tag>
              <item>
                <p>
                  The rights attached to the program must apply to all
                  to whom the program is redistributed without the need
                  for execution of an additional license by those
                  parties.
                </p>
              </item>
              <tag>License Must Not Be Specific to Debian
              </tag>
              <item>
                <p>
                  The rights attached to the program must not depend on
                  the program's being part of a Debian system. If the
                  program is extracted from Debian and used or
                  distributed without Debian but otherwise within the
                  terms of the program's license, all parties to whom
                  the program is redistributed must have the same
                  rights as those that are granted in conjunction with
                  the Debian system.
                </p>
              </item>
              <tag>License Must Not Contaminate Other Software
              </tag>
              <item>
                <p>
                  The license must not place restrictions on other
                  software that is distributed along with the licensed
                  software. For example, the license must not insist
                  that all other programs distributed on the same medium
                  must be free software.
                </p>
              </item>
              <tag>Example Licenses
              </tag>
              <item>
                <p>
                  The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are
                  examples of licenses that we consider <em>free</em>.
                </p>
              </item>
            </taglist>
          </p>
        </sect1>
        <sect1>
          <heading>The main section</heading>
          <p>
            Every package in <em>main</em> and <em>non-US/main</em>
            must comply with the DFSG (Debian Free Software
            Guidelines).</p>

          <p>
            In addition, the packages in <em>main</em>
            <list compact="compact">
              <item>
                <p>
                  must not require a package outside of <em>main</em>
                  for compilation or execution (thus, the package must
                  not declare a "Depends", "Recommends", or
                  "Build-Depends" relationship on a non-<em>main</em>
                  package),
                </p>
              </item>
              <item>
                <p>
                  must not be so buggy that we refuse to support them,
                  and
                </p>
              </item>
              <item>
                <p>
                  must meet all policy requirements presented in this
                  manual.
                </p>
              </item>
            </list>
          </p>
          <p>
            Similarly, the packages in <em>non-US/main</em>
            <list compact="compact">
              <item>
                <p>
                   must not require a package outside of <em>main</em>
                   or <em>non-US/main</em> for compilation or
                   execution,
                </p>
              </item>
              <item>
                <p>
                  must not be so buggy that we refuse to support them,
                </p>
              </item>
              <item>
                <p>
                  must meet all policy requirements presented in this
                  manual.
                </p>
              </item>
            </list>
          </p>
        </sect1>
        <sect1>
          <heading>The contrib section</heading>
          <p>
            Every package in <em>contrib</em> and
            <em>non-US/contrib</em> must comply with the DFSG.
          </p>

          <p>
            In addition, the packages in <em>contrib</em> and
            <em>non-US/contrib</em>
            <list compact="compact">
              <item>
                <p>
                  must not be so buggy that we refuse to support them,
                  and
                </p>
              </item>
              <item>
                <p>
                  must meet all policy requirements presented in this
                  manual.
                </p>
              </item>
            </list>
          </p>

          <p>
            Furthermore, packages in <em>contrib</em> must not require
            a package in a <em>non-US</em> section for compilation or
            execution.
          </p>

          <p>
            Examples of packages which would be included in
            <em>contrib</em> or <em>non-US/contrib</em> are:
            <list compact="compact">
              <item>
                <p>
                  free packages which require <em>contrib</em>,
                  <em>non-free</em> packages or packages which are not
                  in our archive at all for compilation or execution,
                  and
                </p>
              </item>
              <item>
                <p>
                  wrapper packages or other sorts of free accessories for
                  non-free programs.
                </p>
              </item>
            </list>
          </p>
        </sect1>
        <sect1>
          <heading>The non-free section</heading>
          <p>
            Packages must be placed in <em>non-free</em> or
            <em>non-US/non-free</em> if they are not compliant with
            the DFSG or are encumbered by patents or other legal
            issues that make their distribution problematic.
          </p>
          <p>
            In addition, the packages in <em>non-free</em> and
            <em>non-US/non-free</em>
            <list compact="compact">
              <item>
                <p>
                  must not be so buggy that we refuse to support them,
                  and
                </p>
              </item>
              <item>
                <p>
                  must meet all policy requirements presented in this
                  manual that it is possible for them to meet.
                  <footnote>
                    <p>
                      It is possible that there are policy
                      requirements which the package is unable to
                      meet, for example, if the source is
                      unavailable.  These situations will need to be
                      handled on a case-by-case basis.
                    </p>
                  </footnote>
                </p>
              </item>
            </list>
          </p>
        </sect1>

        <sect1>
          <heading>The non-US sections</heading>
          <p>
            Some programs with cryptographic program code need to be
            stored on the <em>non-US</em> server because of United
            States export restrictions.  Such programs must be
            distributed in the appropriate <em>non-US</em> section,
            either <em>non-US/main</em>, <em>non-US/contrib</em> or
            <em>non-US/non-free</em>.
          </p>
          <p>
            This applies only to packages which contain cryptographic
            code. A package containing a program with an interface to
            a cryptographic program or a program that's dynamically
            linked against a cryptographic library should not be
            distributed via the <em>non-US</em> server if it is
            capable of running without the cryptographic library or
            program.
          </p>
        </sect1>
        <sect1>
          <heading>Further copyright considerations</heading>
          <p>
            Every package must be accompanied by a verbatim copy of
            its copyright and distribution license in the file
            <tt>/usr/share/doc/<var>package</var>/copyright</tt>
            (see <ref id="copyrightfile"> for further details).
          </p>
          <p>
            We reserve the right to restrict files from being included
            anywhere in our archives if
            <list compact="compact">
              <item>
                <p>
                  their use or distribution would break a law,
                </p>
              </item>
              <item>
                <p>
                  there is an ethical conflict in their distribution or
                  use,
                </p>
              </item>
              <item>
                <p>
                  we would have to sign a license for them, or
                </p>
              </item>
              <item>
                <p>
                  their distribution would conflict with other project
                  policies.
                </p>
              </item>
            </list>
          </p>

          <p>
            Programs whose authors encourage the user to make
            donations are fine for the main distribution, provided
            that the authors do not claim that not donating is
            immoral, unethical, illegal or something similar; in such
            a case they must go in <em>non-free</em>.</p>

          <p>
            Packages whose copyright permission notices (or patent
            problems) do not even allow redistribution of binaries
            only, and where no special permission has been obtained,
            must not be placed on the Debian FTP site and its mirrors
            at all.</p>

          <p>
            Note that under international copyright law (this applies
            in the United States, too), <em>no</em> distribution or
            modification of a work is allowed without an explicit
            notice saying so.  Therefore a program without a copyright
            notice <em>is</em> copyrighted and you may not do anything
            to it without risking being sued! Likewise if a program
            has a copyright notice but no statement saying what is
            permitted then nothing is permitted.</p>

          <p>
            Many authors are unaware of the problems that restrictive
            copyrights (or lack of copyright notices) can cause for
            the users of their supposedly-free software.  It is often
            worthwhile contacting such authors diplomatically to ask
            them to modify their license terms. However, this can be a
            politically difficult thing to do and you should ask for
            advice on the <tt>debian-legal</tt> mailing list first, as
            explained below.
          </p>

          <p>
            When in doubt about a copyright, send mail to
            <email>debian-legal@lists.debian.org</email>.  Be prepared
            to provide us with the copyright statement.  Software
            covered by the GPL, public domain software and BSD-like
            copyrights are safe; be wary of the phrases `commercial
            use prohibited' and `distribution restricted'.
          </p>
        </sect1>
        <sect1>
          <heading>Subsections</heading>

          <p>
            The packages in the sections <em>main</em>,
            <em>contrib</em> and <em>non-free</em> are grouped further
            into <em>subsections</em> to simplify handling.
          </p>

          <p>
            The section and subsection for each package should be
            specified in the package's <tt>Section</tt> control
            record.  However, the maintainer of the Debian archive
            may override this selection to ensure the consistency of
            the Debian distribution.  The <tt>Section</tt> field
            should be of the form:
            <list compact="compact">
              <item>
                <p>
                  <em>subsection</em> if the package is in the
                  <em>main</em> section,
                </p>
              </item>
              <item>
                <p>
                  <em>section/subsection</em> if the package is in
                  the <em>contrib</em> or <em>non-free</em> section,
                  and
                </p>
              </item>
              <item>
                <p>
                  <tt>non-US</tt>, <tt>non-US/contrib</tt> or
                  <tt>non-US/non-free</tt> if the package is in
                  <em>non-US/main</em>, <em>non-US/contrib</em> or
                  <em>non-US/non-free</em> respectively.
                </p>
              </item>
            </list>
          </p>

          <p>
            The Debian archive maintainers provide the authoritative
            list of subsections.  At present, they are:
            <em>admin</em>, <em>base</em>, <em>comm</em>,
            <em>contrib</em>, <em>devel</em>, <em>doc</em>,
            <em>editors</em>, <em>electronics</em>, <em>games</em>,
            <em>graphics</em>, <em>hamradio</em>,
            <em>interpreters</em>, <em>libs</em>, <em>mail</em>,
            <em>math</em>, <em>misc</em>, <em>net</em>, <em>news</em>,
            <em>non-US</em>, <em>non-free</em>, <em>oldlibs</em>,
            <em>otherosfs</em>, <em>science</em>, <em>shells</em>,
            <em>sound</em>, <em>tex</em>, <em>text</em>,
            <em>utils</em>, <em>web</em>, <em>x11</em>.
          </p>
        </sect1>
      <sect>
        <heading>Priorities</heading>

        <p>
          Each package should have a <em>priority</em> value, which is
          included in the package's <em>control record</em>. This
          information is used by the Debian package management tools
          to separate high-priority packages from less-important
          packages.</p>

        <p>
          The following <em>priority levels</em> are recognised by the
          Debian package management tools.
          <taglist>
            <tag><tt>required</tt></tag>
            <item>
              <p>
                Packages which are necessary for the proper
                functioning of the system.  You must not remove these
                packages or your system may become totally broken and
                you may not even be able to use <prgn>dpkg</prgn> to
                put things back.  Systems with only the
                <tt>required</tt> packages are probably unusable, but
                they do have enough functionality to allow the
                sysadmin to boot and install more software.</p>
            </item>
            <tag><tt>important</tt></tag>
            <item>
              <p>
                Important programs, including those which one would
                expect to find on any Unix-like system.  If the
                expectation is that an experienced Unix person who
                found it missing would say `What on earth is going on,
                where is <prgn>foo</prgn>?', it must be an
                <tt>important</tt> package.
                <footnote>
                  <p>
                    This is an important criterion because we are
                    trying to produce, amongst other things, a free
                    Unix.
                  </p>
                </footnote>
                Other packages without which the system will not run
                well or be usable must also have priority
                <tt>important</tt>.  This does
                <em>not</em> include Emacs, the X Window System, TeX
                or any other large applications.  The
                <tt>important</tt> packages are just a bare minimum of
                commonly-expected and necessary tools.</p>
            </item>
            <tag><tt>standard</tt></tag>
            <item>
              <p>
                These packages provide a reasonably small but not too
                limited character-mode system.  This is what will be
                installed by default if the user doesn't select anything
                else.  It doesn't include many large applications, but
                it does include Emacs (this is more of a piece of
                infrastructure than an application) and a reasonable
                subset of TeX and LaTeX.</p>
            </item>
            <tag><tt>optional</tt></tag>
            <item>
              <p>
                (In a sense everything that isn't required is
                optional, but that's not what is meant here.) This is
                all the software that you might reasonably want to
                install if you didn't know what it was and don't have
                specialized requirements. This is a much larger system
                and includes the X Window System, a full TeX
                distribution, and many applications. Note that
                optional packages should not conflict with each other.
              </p>
            </item>
            <tag><tt>extra</tt></tag>
            <item>
              <p>
                This contains all packages that conflict with others
                with required, important, standard or optional
                priorities, or are only likely to be useful if you
                already know what they are or have specialised
                requirements.
              </p>
            </item>
          </taglist></p>

        <p>
          Packages must not depend on packages with lower priority
          values (excluding build-time dependencies).  In order to
          ensure this, the priorities of one or more packages may need
          to be adjusted.
        </p>
      </sect>

      <sect>
        <heading>Binary packages</heading>

        <p>
          The Debian GNU/Linux distribution is based on the Debian
          package management system, called <prgn>dpkg</prgn>. Thus,
          all packages in the Debian distribution must be provided
          in the <tt>.deb</tt> file format.</p>


        <sect1>
          <heading>The package name</heading>

          <p>
            Every package must have a name that's unique within the Debian
            archive.</p>

          <p>
            Package names must consist of lower case letters
            (<tt>a-z</tt>), digits (<tt>0-9</tt>), plus (<tt>+</tt>)
            and minus (<tt>-</tt>) signs, and periods (<tt>.</tt>).
            They must be at least two characters long and must contain
            at least one letter.
          </p>

          <p>
            The package name is part of the file name of the
            <tt>.deb</tt> file and is included in the control field
            information.
          </p>
        </sect1>

        <sect1>
          <heading>The maintainer of a package</heading>
         <p>
            Every package must have a Debian maintainer (the
            maintainer may be one person or a group of people
            reachable from a common email address, such as a mailing
            list).  The maintainer is responsible for ensuring that
            the package is placed in the appropriate distributions.
          </p>

          <p>
            The maintainer must be specified in the
            <tt>Maintainer</tt> control field with their correct name
            and a working email address.  If one person maintains
            several packages, he/she should try to avoid having
            different forms of their name and email address in
            the <tt>Maintainer</tt> fields of those packages.
          </p>

          <p>
            If the maintainer of a package quits from the Debian
            project, "Debian QA Group"
            <email>packages@qa.debian.org</email> takes over the
            maintainership of the package until someone else
            volunteers for that task. These packages are called
            <em>orphaned packages</em>.
            <footnote>
              <p>
                The detailed procedure for doing this gracefully can
                be found in the Debian Developer's Reference, either
                in the <tt>developers-reference</tt> package, or on
                the Debian FTP server
                <ftpsite>ftp.debian.org</ftpsite> as
                <ftppath>/debian/doc/package-developer/developers-reference.txt.gz</ftppath>
                or from the <url
                id="http://www.debian.org/doc/packaging-manuals/developers-reference/"
                name="Debian Developer's Reference"> webpage.
              </p>
            </footnote>
          </p>
        </sect1>


        <sect1>
          <heading>The description of a package</heading>

          <p>
            Every Debian package must have an extended description
            stored in the appropriate field of the control record.</p>

          <p>
            The description should be written so that it gives the
            system administrator enough information to decide whether
            to install the package. This description should not just
            be copied verbatim from the program's documentation.
            Instructions for configuring or using the package should
            not be included (that is what installation scripts,
            manual pages, info files, etc., are for).  Copyright
            statements and other administrivia should not be included
            either (that is what the copyright file is for).
          </p>
        </sect1>


        <sect1>
          <heading>Dependencies</heading>

          <p>
            Every package must specify the dependency information
            about other packages that are required for the first to
            work correctly.</p>

          <p>
            For example, a dependency entry must be provided for any
            shared libraries required by a dynamically-linked executable
            binary in a package.</p>

          <p>
            Packages are not required to declare any dependencies they
            have on other packages which are marked <tt>Essential</tt>
            (see below), and should not do so unless they depend on a
            particular version of that package.</p>

          <p>
            Sometimes, a package requires another package to be installed
            <em>and</em> configured before it can be installed. In this
            case, you must specify a <tt>Pre-Depends</tt> entry for
            the package.</p>

          <p>
            You should not specify a <tt>Pre-Depends</tt> entry for a
            package before this has been discussed on the
            <tt>debian-devel</tt> mailing list and a consensus about
            doing that has been reached.</p></sect1>


        <sect1>
          <heading>Virtual packages</heading>

          <p>
            Sometimes, there are several packages which offer
            more-or-less the same functionality. In this case, it's
            useful to define a <em>virtual package</em> whose name
            describes that common functionality.  (The virtual
            packages only exist logically, not physically; that's why
            they are called <em>virtual</em>.) The packages with this
            particular function will then <em>provide</em> the virtual
            package. Thus, any other package requiring that function
            can simply depend on the virtual package without having to
            specify all possible packages individually.</p>

          <p>
            All packages should use virtual package names where
            appropriate, and arrange to create new ones if necessary.
            They should not use virtual package names (except privately,
            amongst a cooperating group of packages) unless they have
            been agreed upon and appear in the list of virtual package
            names.</p>

          <p>
            The latest version of the authoritative list of virtual
            package names can be found on
            <ftpsite>ftp.debian.org</ftpsite> in
            <ftppath>/debian/doc/package-developer/virtual-package-names-list.txt</ftppath>
            or your local mirror. In addition, it is included in the
            <tt>debian-policy</tt> package. The procedure for updating
            the list is described at the top of the file.</p></sect1>


        <sect1>
          <heading>Base packages</heading>

          <p>
            The packages included in the <tt>base</tt> section have a
            special function. They form a minimum subset of the Debian
            GNU/Linux system that is installed before everything else
            on a new system. Thus, only very few packages are allowed
            to go into the <tt>base</tt> section to keep the required
            disk usage very small.</p>

          <p>
            Most of these packages will have the priority value
            <tt>required</tt> or at least <tt>important</tt>, and many
            of them will be tagged <tt>essential</tt> (see below).</p>

          <p>
            You must not place any packages into the <tt>base</tt>
            section before this has been discussed on the
            <tt>debian-devel</tt> mailing list and a consensus about
            doing that has been reached.</p></sect1>


        <sect1>
          <heading>Essential packages</heading>

          <p>
            Some packages are tagged <tt>essential</tt>. (They have
            <tt>Essential: yes</tt> in their package control record.)
            This flag is used for packages that are <em>essential</em>
            for a system.</p>

          <p>
            Since these packages cannot be easily removed (one has to
            specify an extra <em>force option</em> to
            <prgn>dpkg</prgn> to do so), this flag must not be used
            unless absolutely necessary.  A shared library package
            must not be tagged <tt>essential</tt>; dependencies will
            prevent its premature removal, and we need to be able to
            remove it when it has been superseded.
          </p>

          <p>
            Since dpkg will not prevent upgrading of other packages
            while an <tt>essential</tt> package is in an unconfigured
            state, all <tt>essential</tt> packages must supply all of
            their core functionality even when unconfigured. If the
            package cannot satisfy this requirement it must not be
            tagged as essential, and any packages depending on this
            package must instead have explicit dependency fields as
            appropriate.
          </p>

          <p>
            You must not tag any packages <tt>essential</tt> before
            this has been discussed on the <tt>debian-devel</tt>
            mailing list and a consensus about doing that has been
            reached.
          </p>
        </sect1>

        <sect1 id="maintscripts">
          <heading>Maintainer scripts</heading>

          <p>
            The package installation scripts should avoid producing
            output which it is unnecessary for the user to see and
            should rely on <prgn>dpkg</prgn> to stave off boredom on
            the part of a user installing many packages.  This means,
            amongst other things, using the <tt>--quiet</tt> option on
            <prgn>install-info</prgn>.</p>

          <p>
            Errors which occur during the execution of an installation
            script must be checked and the installation must not
            continue after an error.
          </p>

          <p>
            Note that in general <ref id="scripts"> applies to package
            maintainer scripts, too.
          </p>

          <p>
            You should not use <tt>dpkg-divert</tt> on a file
            belonging to another package without consulting the
            maintainer of that package first.
          </p>

          <p>
            All packages which supply an instance of a common command
            name (or, in general, filename) should generally use
            <prgn>update-alternatives</prgn>, so that they may be
            installed together.  If <prgn>update-alternatives</prgn>
            is not used, then each package must use
            <tt>Conflicts</tt> to ensure that other packages are
            de-installed.  (In this case, it may be appropriate to
            specify a conflict against earlier versions of something
            that previously did not use
            <prgn>update-alternatives</prgn>; this is an exception to
            the usual rule that versioned conflicts should be
            avoided.)
          </p>


          <sect2>
            <heading>Prompting in maintainer scripts</heading>
            <p>
              Package maintainer scripts may prompt the user if
              necessary. Prompting may be accomplished by hand, or by
              communicating with a program, such as
              <prgn>debconf</prgn>, which conforms to the Debian
              Configuration management specification, version 2 or
              higher.  These are included in the
              <file>debconf_specification</file> files in the
              <package>debian-policy</package> package.
              You may also find this file on the FTP site
              <ftpsite>ftp.debian.org</ftpsite> in
              <ftppath>/debian/doc/package-developer/debconf_specification.txt.gz</ftppath>
              or on your local mirror.
              <footnote>
                <p>
                  2.5% of Debian packages [see <url
                  id="http://kitenet.net/programs/debconf/stats/"
                  name="Debconf stats">] currently use
                  <package>debconf</package> to prompt the user at
                  install time, and this number is growing daily. The
                  benefits of using debconf are briefly explained at
                  <url
                  id="http://kitenet.net/doc/debconf-doc/introduction.html"
                  name="Debconf introduction">; they include
                  preconfiguration, (mostly) noninteractive
                  installation, elimination of redundant prompting,
                  consistency of user interface, etc.
                </p>
                <p>
                  With this increasing number of packages using
                  <package>debconf</package>, plus the existance of a
                  nascent second implementation of the Debian
                  configuration management system
                  (<package>cdebconf</package>), and the stabalization
                  of the protocol these things use, the time has
                  finally come to reflect the use of these things in
                  policy.

                </p>
              </footnote>
            </p>
            <p>
              Packages which use the Debian Configuration management
              specification may contain an additional
              <file>config</file> script and a <file>templates</file>
              file in their control archive. The <prgn>config</prgn>
              script might be run before the <prgn>preinst</prgn>
              script, and before the package is unpacked or any of its
              dependancies or pre-dependancies are satisfied.
              Therefore it must work using only the tools present in
              <em>essential</em> packages.
              <footnote>
                <p>
                  <package>Debconf</package> or another tool that
                  implements the Debian Configuration management
                  specification will also be installed, and any
                  versioned dependencies on it will be satisfied
                  before preconfiguration begins.
                </p>
              </footnote>
            </p>

            <p>
              Packages should try to minimize the amount of prompting
              they need to do, and they should ensure that the user
              will only ever be asked each question once.  This means
              that packages should try to use appropriate shared
              configuration files (such as <tt>/etc/papersize</tt> and
              <tt>/etc/news/server</tt>), and shared
              <package>debconf</package> variables rather than each
              prompting for their own list of required pieces of
              information.
            </p>

            <p>
              It also means that an upgrade should not ask the same
              questions again, unless the user has used <tt>dpkg
                --purge</tt> to remove the package's configuration.  The
              answers to configuration questions should be stored in an
              appropriate place in <tt>/etc</tt> so that the user can
              modify them, and how this has been done should be
              documented.</p>

            <p>
              If a package has a vitally important piece of
              information to pass to the user (such as "don't run me
              as I am, you must edit the following configuration files
              first or you risk your system emitting badly-formatted
              messages"), it should display this in the
              <prgn>config</prgn> or <prgn>postinst</prgn> script and
              prompt the user to hit return to acknowledge the
              message.  Copyright messages do not count as vitally
              important (they belong in
              <tt>/usr/share/doc/<var>package</var>/copyright</tt>);
              neither do instructions on how to use a program (these
              should be in on-line documentation, where all the users
              can see them).</p>

            <p>
              Any necessary prompting should almost always be confined
              to the <prgn>config</prgn> or <prgn>postinst</prgn>
              script. If it is done in the <prgn>postinst</prgn>, it
              should be protected with a conditional so that
              unnecessary prompting doesn't happen if a package's
              installation fails and the <prgn>postinst</prgn> is
              called with <tt>abort-upgrade</tt>,
              <tt>abort-remove</tt> or <tt>abort-deconfigure</tt>.</p>
        </sect1>
      </sect>

      <sect>
        <heading>Source packages</heading>

        <sect1 id="standardsversion">
          <heading>Standards conformance</heading>

          <p>
            In the source package's <tt>Standards-Version</tt> control
            field, you must specify the most recent version number of
            this policy document with which your package complies.
            The current version number is &version;.
          </p>

          <p>
            This information may be used to file bug reports
            automatically if your package becomes too much out of
            date.
          </p>

          <p>
            The version number has four components: major and minor
            version number and major and minor patch level.  When the
            standards change in a way that requires every package to
            change the major number will be changed.  Significant
            changes that will require work in many packages will be
            signaled by a change to the minor number.  The major patch
            level will be changed for any change to the meaning of the
            standards, however small; the minor patch level will be
            changed when only cosmetic, typographical or other edits
            are made which neither change the meaning of the document
            nor affect the contents of packages.</p>

          <p>
            Thus only the first three components of the policy version
            are significant in the <em>Standards-Version</em> control
            field, and so either these three components or the all
            four components may be specified.
            <footnote>
              <p>
                In the past, people specified the full version number
                in the Standards-Version field, for example `2.3.0.0'.
                Since minor patch-level changes don't introduce new
                policy, it was thought it would be better to relax
                policy and only require the first 3 components to be
                specified, in this example `2.3.0'.  All four
                components may still be used if someone wishes to do
                so.
              </p>
            </footnote>
          </p>

          <p>
            You should regularly, and especially if your package has
            become out of date, check for the newest Policy Manual
            available and update your package, if necessary. When your
            package complies with the new standards you should update the
            <tt>Standards-Version</tt> source package field and
            release it.
            <footnote>
              <p>
                See the file <tt>upgrading-checklist</tt> for
                information about policy which has changed between
                different versions of this document.
              </p>
            </footnote>
          </p>
        </sect1>


        <sect1>
          <heading>Package relationships</heading>

          <p>
            Source packages should specify which binary packages they
            require to be installed or not to be installed in order to
            build correctly.  For example, if building a package
            requires a certain compiler, then the compiler should be
            specified as a build-time dependency.
          </p>

          <p>
            It is not necessary to explicitly specify build-time
            relationships on a minimal set of packages that are always
            needed to compile, link and put in a Debian package a
            standard "Hello World!" program written in C or C++.  The
            required packages are called <em>build-essential</em>, and
            an informational list can be found in
            <tt>/usr/share/doc/build-essential/list</tt> (which is
            contained in the <tt>build-essential</tt>
            package).
            <footnote>
              <p>Rationale:
                <list compact="compact">
                  <item>
                    <p>This allows maintaining the list separately
                      from the policy documents (the list does not
                      need the kind of control that the policy
                      documents do).
                    </p>
                  </item>
                  <item>
                    <p>
                      Having a separate package allows one to install
                      the build-essential packages on a machine, as
                      well as allowing other packages such as task
                      packages to require installation of the
                      build-essential packages using the depends
                      relation.
                    </p>
                  </item>
                  <item>
                    <p>
                      The separate package allows bug reports against
                      the list to be categorized separately from
                      the policy management process in the BTS.
                    </p>
                  </item>
                </list>
              </p>

            </footnote>
          </p>

          <p>
            When specifying the set of build-time dependencies, one
            should list only those packages explicitly required by the
            build.  It is not necessary to list packages which are
            required merely because some other package in the list of
            build-time dependencies depends on them.
            <footnote>
              <p>
                The reason for this is that dependencies change, and
                you should list all those packages, and <em>only</em>
                those packages that <em>you</em> need directly.  What
                others need is their business.  For example, if you
                only link against <tt>libimlib</tt>, you will need to
                build-depend on <package>libimlib2-dev</package> but
                not against any <tt>libjpeg*</tt> packages, even
                though <tt>libimlib2-dev</tt> currently depends on
                them: installation of <package>libimlib2-dev</package>
                will automatically ensure that all of its run-time
                dependencies are satisfied.
              </p>
            </footnote>
          </p>

          <p>
            If build-time dependencies are specified, it must be
            possible to build the package and produce working binaries
            on a system with only essential and build-essential
            packages installed and also those required to satisfy the
            build-time relationships (including any implied
            relationships).  In particular, this means that version
            clauses should be used rigorously in build-time
            relationships so that one cannot produce bad or
            inconsistently configured packages when the relationships
            are properly satisfied.
          </p>

        <sect1>
          <heading>Changes to the upstream sources</heading>

          <p>
            If changes to the source code are made that are not
            specific to the needs of the Debian system, they should be
            sent to the upstream authors in whatever form they prefer
            so as to be included in the upstream version of the
            package.</p>

          <p>
            If you need to configure the package differently for
            Debian or for Linux, and the upstream source doesn't
            provide a way to do so, you should add such configuration
            facilities (for example, a new <prgn>autoconf</prgn> test
            or <tt>#define</tt>) and send the patch to the upstream
            authors, with the default set to the way they originally
            had it.  You can then easily override the default in your
            <tt>debian/rules</tt> or wherever is appropriate.</p>

          <p>
            You should make sure that the <prgn>configure</prgn> utility
            detects the correct architecture specification string
            (refer to <ref id="arch-spec"> for details).</p>

          <p>
            If you need to edit a <prgn>Makefile</prgn> where
            GNU-style <prgn>configure</prgn> scripts are used, you
            should edit the <tt>.in</tt> files rather than editing the
            <prgn>Makefile</prgn> directly.  This allows the user to
            reconfigure the package if necessary.  You should
            <em>not</em> configure the package and edit the generated
            <prgn>Makefile</prgn>!  This makes it impossible for
            someone else to later reconfigure the package.</p></sect1>


        <sect1>
          <heading>Documenting your changes</heading>

          <p>
            You should document your changes and updates to the source
            package properly in the <tt>debian/changelog</tt> file. (Note
            that mistakes in changelogs are usually best rectified by
            making a new changelog entry rather than "rewriting history"
            by editing old changelog entries.)</p>

          <p>
            In non-experimental packages you must use a format for
            <tt>debian/changelog</tt> which is supported by the most
            recent released version of <prgn>dpkg</prgn>.
            <footnote>
              <p>
                If you wish to use an alternative format, you may do
                so as long as you include a parser for it in your
                source package.  The parser must have an API
                compatible with that expected by
                <prgn>dpkg-genchanges</prgn> and
                <prgn>dpkg-gencontrol</prgn>.  If there is general
                interest in the new format, you should contact the
                <package>dpkg</package> maintainer to have the parser
                script for it included in the <prgn>dpkg</prgn>
                package.  (You will need to agree that the parser and
                its manpage may be distributed under the GNU GPL, just
                as the rest of `dpkg' is.)
              </p>
            </footnote>
          </p>
        </sect1>


        <sect1>
          <heading>Error trapping in makefiles</heading>

          <p>
            When <prgn>make</prgn> invokes a command in a makefile
            (including your package's upstream makefiles and
            <tt>debian/rules</tt>), it does so using <tt>sh</tt>.  This
            means that <tt>sh</tt>'s usual bad error handling
            properties apply: if you include a miniature script as one
            of the commands in your makefile you'll find that if you
            don't do anything about it then errors are not detected
            and <prgn>make</prgn> will blithely continue after
            problems.</p>

          <p>
            Every time you put more than one shell command (this
            includes using a loop) in a makefile command you
            must make sure that errors are trapped.  For
            simple compound commands, such as changing directory and
            then running a program, using <tt>&amp;&amp;</tt> rather
            than semicolon as a command separator is sufficient.  For
            more complex commands including most loops and
            conditionals you should include a separate <tt>set -e</tt>
            command at the start of every makefile command that's
            actually one of these miniature shell scripts.</p></sect1>


        <sect1>
          <heading>Obsolete constructs and libraries</heading>

          <p>
            The include file <tt>&lt;varargs.h&gt;</tt> is
            provided to support end-users compiling very old software;
            the library <tt>libtermcap</tt> is provided to support the
            execution of software which has been linked against it
            (either old programs or those such as Netscape which are
            only available in binary form).</p>

          <p>
            Debian packages should be patched to use
            <tt>&lt;stdarg.h&gt;</tt> and <tt>ncurses</tt>
            instead.
          </p>
        </sect1>
      </sect>
    </chapt>

    <chapt id="controlfields"><heading>Control files and their fields</heading>

      <p>
        Many of the tools in the package management suite manipulate
        data represented in a common format, known as <em>control
        data</em>.  The data is often stored in <em>control
        files</em>.  Binary and source packages have control files,
        and the <tt>.changes</tt> files which control the installation
        of uploaded files are also in control file format.
        <prgn>Dpkg</prgn>'s internal databases are in a similar
        format.
      </p>

      <sect id="controlsyntax"><heading>Syntax of control files</heading>

        <p>
          A control file consists of one or more paragraphs of fields.
          The paragraphs are separated by blank lines.  Some control
          files allow only one paragraph; others allow several, in
          which case each paragraph usually refers to a different
          package.  (For example, in source packages, the first
          paragraph refers to the source package, and later paragraphs
          refer to binary packages generated from the source.)
        </p>

        <p>
          Each paragraph consists of a series of data fields; each
          field consists of the field name, followed by a colon and
          then the data/value associated with that field.  It ends at
          the end of the line.  Horizontal whitespace (spaces and
          tabs) may occur immediately before or after the value and is
          ignored there; it is conventional to put a single space
          after the colon.  For example, a field might be:
          <example compact="compact">
Package: libc6
          </example>
          the field name is <tt>Package</tt> and the field value
          <tt>libc6</tt>.
        </p>

        <p>
          Some fields' values may span several lines; in this case
          each continuation line <em>must</em> start with a space or
          tab.  Any trailing spaces or tabs at the end of individual
          lines of a field value are ignored.
        </p>

        <p>
          Except where otherwise stated only a single line of data is
          allowed and whitespace is not significant in a field body.
          Whitespace must not appear inside names (of packages,
          architectures, files or anything else) or version numbers,
          or between the characters of multi-character version
          relationships.
        </p>

        <p>
          Field names are not case-sensitive, but it is usual to
          capitalize the field names using mixed case as shown below.
        </p>

        <p>
          Blank lines, or lines consisting only of spaces and tabs,
          are not allowed within field values or between fields - that
          would mean a new paragraph.
        </p>

      </sect>

      <sect><heading>List of fields</heading>
        <p>
          This list here is not supposed to be exhaustive. Most fields
          are dealt with elsewhere in this document.
        </p>
        <sect1 id="f-Package"><heading><tt>Package</tt>
          </heading>

          <p>
            The name of the binary package.  Package names consist of
            the alphanumerics and <tt>+</tt> <tt>-</tt> <tt>.</tt>
            (plus, minus and full stop).
          </p>

          <p>
            They must be at least two characters long and must start
            with an alphanumeric character and not be all digits.  The
            use of lowercase package names is strongly recommended
            unless the package you're building (or referring to, in
            other fields) is already using uppercase.</p>
        </sect1>

        <sect1 id="f-Version"><heading><tt>Version</tt>
          </heading>

          <p>
            This lists the source or binary package's version number -
            see <ref id="versions">.
          </p>

        </sect1>

        <sect1
               id="f-Standards-Version"><heading><tt>Standards-Version</tt>
          </heading>

          <p>
            The most recent version of the standards (the policy
            manual and associated texts) with which the package
            complies.  This is updated manually when editing the
            source package to conform to newer standards; it can
            sometimes be used to tell when a package needs attention.
            Its format is described above; see
            <ref id="standardsversion">.
          </p>
        </sect1>


        <sect1 id="f-Distribution"><heading><tt>Distribution</tt>
          </heading>

          <p>
            In a <tt>.changes</tt> file or parsed changelog output
            this contains the (space-separated) name(s) of the
            distribution(s) where this version of the package should
            be installed.  Valid distributions are determined by the
            archive maintainers.
            <footnote>
                Current distribution names are:
                <taglist compact="compact">
                  <tag><em>stable</em></tag>
                  <item>
                    <p>
                      This is the current `released' version of Debian
                      GNU/Linux.  Once the distribution is
                      <em>stable</em> only security fixes and other
                      major bug fixes are allowed. When changes are
                      made to this distribution, the release number is
                      increased (for example: 2.2r1 becomes 2.2r2 then
                      2.2r3, etc).
                    </p>
                  </item>

                  <tag><em>unstable</em></tag>
                  <item>
                    <p>
                      This distribution value refers to the
                      <em>developmental</em> part of the Debian
                      distribution tree. New packages, new upstream
                      versions of packages and bug fixes go into the
                      <em>unstable</em> directory tree. Download from
                      this distribution at your own risk.
                    </p>
                  </item>

                  <tag><em>testing</em></tag>
                  <item>
                    <p>
                      This distribution value refers to the
                      <em>testing</em> part of the Debian distribution
                      tree.  It receives its packages from the
                      unstable distribution after a short time lag to
                      ensure that there are no major issues with the
                      unstable packages.  It is less prone to breakage
                      than unstable, but still risky.  It is not
                      possible to upload packages directly to
                      <em>testing</em>.
                    </p>
                  </item>

                  <tag><em>frozen</em></tag>
                  <item>
                    <p>
                      From time to time, the <em>testing</em>
                      distribution enters a state of `code-freeze' in
                      anticipation of release as a <em>stable</em>
                      version. During this period of testing only
                      fixes for existing or newly-discovered bugs will
                      be allowed.  The exact details of this stage are
                      determined by the Release Manager.
                    </p>
                  </item>

                  <tag><em>experimental</em></tag>
                  <item>
                    <p>
                      The packages with this distribution value are
                      deemed by their maintainers to be high
                      risk. Oftentimes they represent early beta or
                      developmental packages from various sources that
                      the maintainers want people to try, but are not
                      ready to be a part of the other parts of the
                      Debian distribution tree. Download at your own
                      risk.
                    </p>
                  </item>
                </taglist>

                You should list <em>all</em> distributions that the
                package should be installed into.
            </footnote>
          </p>
        </sect1>


      </sect>
    </chapt>

    <chapt id="versions"><heading>Version numbering</heading>

      <p>
        Every package has a version number recorded in its
        <tt>Version</tt> control file field.
      </p>

      <p>
        The package management system imposes an ordering on version
        numbers, so that it can tell whether packages are being up- or
        downgraded and so that package system front end applications
        can tell whether a package it finds available is newer than
        the one installed on the system.  The version number format
        has the most significant parts (as far as comparison is
        concerned) at the beginning.
      </p>

      <p>
        The version number format is:
        &lsqb;<var>epoch</var><tt>:</tt>&rsqb;<var>upstream_version</var>&lsqb;<tt>-</tt><var>debian_revision</var>&rsqb;
      </p>

      <p>
        The three components here are:
        <taglist>
          <tag><var>epoch</var></tag>
          <item>

            <p>
              This is a single (generally small) unsigned integer.  It
              may be omitted, in which case zero is assumed.  If it is
              omitted then the <var>upstream_version</var> may not
              contain any colons.
            </p>

            <p>
              It is provided to allow mistakes in the version numbers
              of older versions of a package, and also a package's
              previous version numbering schemes, to be left behind.
            </p>

          </item>

          <tag><var>upstream_version</var></tag>
          <item>

            <p>
              This is the main part of the version number.  It is
              usually the version number of the original (`upstream')
              package from which the <tt>.deb</tt> file has been made,
              if this is applicable.  Usually this will be in the same
              format as that specified by the upstream author(s);
              however, it may need to be reformatted to fit into the
              package management system's format and comparison
              scheme.
            </p>

            <p>
              The comparison behavior of the package management system
              with respect to the <var>upstream_version</var> is
              described below.  The <var>upstream_version</var>
              portion of the version number is mandatory.
            </p>

            <p>
              The <var>upstream_version</var> may contain only
              alphanumerics
              <footnote>
                <p>Alphanumerics are <tt>A-Za-z0-9</tt> only.</p>
              </footnote>
              and the characters <tt>.</tt> <tt>+</tt> <tt>-</tt>
              <tt>:</tt> (full stop, plus, hyphen, colon) and should
              start with a digit.  If there is no
              <var>debian_revision</var> then hyphens are not allowed;
              if there is no <var>epoch</var> then colons are not
              allowed.</p>
          </item>

          <tag><var>debian_revision</var></tag>
          <item>

            <p>
              This part of the version number specifies the version of
              the Debian package based on the upstream version.  It
              may contain only alphanumerics and the characters
              <tt>+</tt> and <tt>.</tt> (plus and full stop) and is
              compared in the same way as the
              <var>upstream_version</var> is.
            </p>

            <p>
              It is optional; if it isn't present then the
              <var>upstream_version</var> may not contain a hyphen.
              This format represents the case where a piece of
              software was written specifically to be turned into a
              Debian package, and so there is only one `debianization'
              of it and therefore no revision indication is required.
            </p>

            <p>
              It is conventional to restart the
              <var>debian_revision</var> at <tt>1</tt> each time the
              <var>upstream_version</var> is increased.
            </p>

            <p>
              The package management system will break the version
              number apart at the last hyphen in the string (if there
              is one) to determine the <var>upstream_version</var> and
              <var>debian_revision</var>.  The absence of a
              <var>debian_revision</var> compares earlier than the
              presence of one (but note that the
              <var>debian_revision</var> is the least significant part
              of the version number).
            </p>
          </item>
        </taglist>
      </p>

      <p>
        The <var>upstream_version</var> and <var>debian_revision</var>
        parts are compared by the package management system using the
        same algorithm:
      </p>

      <p>
        The strings are compared from left to right.
      </p>

      <p>
        First the initial part of each string consisting entirely of
        non-digit characters is determined.  These two parts (one of
        which may be empty) are compared lexically.  If a difference
        is found it is returned.  The lexical comparison is a
        comparison of ASCII values modified so that all the letters
        sort earlier than all the non-letters.
      </p>

      <p>
        Then the initial part of the remainder of each string which
        consists entirely of digit characters is determined.  The
        numerical values of these two parts are compared, and any
        difference found is returned as the result of the comparison.
        For these purposes an empty string (which can only occur at
        the end of one or both version strings being compared) counts
        as zero.
      </p>

      <p>
        These two steps (comparing and removing initial non-digit
        strings and initial digit strings) are repeated until a
        difference is found or both strings are exhausted.
      </p>

      <p>
        Note that the purpose of epochs is to allow us to leave behind
        mistakes in version numbering, and to cope with situations
        where the version numbering scheme changes.  It is
        <em>not</em> intended to cope with version numbers containing
        strings of letters which the package management system cannot
        interpret (such as <tt>ALPHA</tt> or <tt>pre-</tt>), or with
        silly orderings (the author of this manual has heard of a
        package whose versions went <tt>1.1</tt>, <tt>1.2</tt>,
        <tt>1.3</tt>, <tt>1</tt>, <tt>2.1</tt>, <tt>2.2</tt>,
        <tt>2</tt> and so forth).
      </p>

      <p>
        If an upstream package has problematic version numbers they
        should be converted to a sane form for use in the
        <tt>Version</tt> field.
      </p>

      <sect>
        <heading>Version numbers based on dates</heading>
        <p>
          In general, Debian packages should use the same version
          numbers as the upstream sources.</p>

        <p>
          However, in some cases where the upstream version number is
          based on a date (e.g., a development `snapshot' release) the
          package management system cannot handle these version
          numbers without epochs. For example, dpkg will consider
          `96May01' to be greater than `96Dec24'.</p>

        <p>
          To prevent having to use epochs for every new upstream
          version, the version number should be changed to the
          following format in such cases: `19960501', `19961224'. It
          is up to the maintainer whether he/she wants to bother the
          upstream maintainer to change the version numbers upstream,
          too.</p>

        <p>
          Note that other version formats based on dates which are
          parsed correctly by the package management system should
          <em>not</em> be changed.</p>

        <p>
          Native Debian packages (i.e., packages which have been
          written especially for Debian) whose version numbers include
          dates should always use the `YYYYMMDD' format.</p>
      </sect>
    </chapt>

    <chapt id="miscellaneous"><heading>Packaging Considerations</heading>

      <sect id="timestamps"><heading>Time Stamps</heading>
        <p>
          Maintainers should preserve the modification times of the
          upstream source files in a package, as far as is reasonably
          possible.
          <footnote>
            <p>
              The rationale is that there is some information conveyed
              by knowing the age of the file, for example, you could
              recognize that some documentation is very old by looking
              at the modification time, so it would be nice if the
              modification time of the upstream source would be
              preserved.
            </p>
          </footnote>
        </p>
      </sect>

      <sect id="debianrules"><heading><tt>debian/rules</tt> - the
          main building script</heading>

        <p>
          This file must be an executable makefile, and contains the
          package-specific recipes for compiling the package and
          building binary package(s) from the source.
        </p>

        <p>
          It must start with the line <tt>#!/usr/bin/make -f</tt>,
          so that it can be invoked by saying its name rather than
          invoking <prgn>make</prgn> explicitly.
        </p>

        <p>
          Since an interactive <tt>debian/rules</tt> script makes it
          impossible to auto-compile that package and also makes it
          hard for other people to reproduce the same binary
          package, all <em>required targets</em> MUST be
          non-interactive. At a minimum, required targets are the
          ones called by <prgn>dpkg-buildpackage</prgn>, namely,
          <em>clean</em>, <em>binary</em>, <em>binary-arch</em>,
          <em>binary-indep</em>, and <em>build</em>. It also follows
          that any target that these targets depend on must also be
          non-interactive.
        </p>

        <p>
          The required and optional targets are as follows:
          <taglist>
            <tag><tt>build</tt></tag>
            <item>
              <p>
                This should perform all non-interactive configuration
                and compilation of the package.  If a package has an
                interactive pre-build configuration routine, the
                Debianized source package must either be built after
                this has taken place (so that the binary package can
                be built without rerunning the configuration) or the
                configuration routine modified to become
                non-interactive.  (The latter is preferable if there
                are architecture-specific features detected by the
                configuration routine.)
              </p>

              <p>
                For some packages, notably ones where the same
                source tree is compiled in different ways to produce
                two binary packages, the <prgn>build</prgn> target
                does not make much sense.  For these packages it is
                good enough to provide two (or more) targets
                (<tt>build-a</tt> and <tt>build-b</tt> or whatever)
                for each of the ways of building the package, and a
                <prgn>build</prgn> target that does nothing.  The
                <prgn>binary</prgn> target will have to build the
                package in each of the possible ways and make the
                binary package out of each.
              </p>

              <p>
                The <prgn>build</prgn> target must not do anything
                that might require root privilege.
              </p>

              <p>
                The <prgn>build</prgn> target may need to run the
                <prgn>clean</prgn> target first - see below.
              </p>

              <p>
                When a package has a configuration and build routine
                which takes a long time, or when the makefiles are
                poorly designed, or when <prgn>build</prgn> needs to
                run <prgn>clean</prgn> first, it is a good idea to
                <tt>touch build</tt> when the build process is
                complete.  This will ensure that if <tt>debian/rules
                build</tt> is run again it will not rebuild the whole
                program.
                <footnote>
                  <p>
                    Another common way to do this is for <prgn>build</prgn>
                    to depend on <prgn>build-stamp</prgn> and to do
                    nothing else, and for the <prgn>build-stamp</prgn>
                    target to do the building and to <tt>touch
                    build-stamp</tt> on completion.  This is
                    especially useful if the build routine creates a
                    file or directory called <tt>build</tt>; in such a
                    case, <prgn>build</prgn> will need to be listed as
                    a phony target (i.e., as a dependency of the
                    <tt>.PHONY</tt> target).  See the documentation of
                    <prgn>make</prgn> for more information on phony
                    targets.
                  </p>
                </footnote>
              </p>
            </item>

            <tag><tt>binary</tt>, <tt>binary-arch</tt>,
              <tt>binary-indep</tt>
            </tag>
            <item>
              <p>
                The <prgn>binary</prgn> target must be all that is
                necessary for the user to build the binary package(s)
                produced from this source package.  All of these
                targets are required to be non-interactive.  It is
                split into two parts: <prgn>binary-arch</prgn> builds
                the binary packages which are specific to a particular
                architecture, and <prgn>binary-indep</prgn> builds
                those which are not.
              </p>

              <p>
                <prgn>binary</prgn> may be (and commonly is) a target
                with no commands which simply depends on
                <prgn>binary-arch</prgn> and
                <prgn>binary-indep</prgn>.
              </p>

              <p>
                Each <prgn>binary-*</prgn> target should depend on
                the <prgn>build</prgn> target, above, so that the
                package is built if it has not been already.  It
                should then create the relevant binary package(s),
                using <prgn>dpkg-gencontrol</prgn> to make their
                control files and <prgn>dpkg-deb</prgn> to build
                them and place them in the parent of the top level
                directory.
              </p>

              <p>
                Both the <prgn>binary-arch</prgn> and
                <prgn>binary-indep</prgn> targets <em>must</em> exist.
                If one of them has nothing to do (which will always be
                the case if the source generates only a single binary
                package, whether architecture-dependent or not), it
                must still exist and must always succeed.
              </p>

              <p>
                The <prgn>binary</prgn> targets must be invoked as
                root.
                <footnote>
                  <p>
                    The <prgn>fakeroot</prgn> package often allows one
                    to build a package correctly even without being
                    root.
                  </p>
                </footnote>
              </p>
            </item>

            <tag><tt>clean</tt></tag>
            <item>

              <p>
                This must undo any effects that the <prgn>build</prgn>
                and <prgn>binary</prgn> targets may have had, except
                that it should leave alone any output files created in
                the parent directory by a run of a <prgn>binary</prgn>
                target. This target must be non-interactive.
              </p>

              <p>
                If a <prgn>build</prgn> file is touched at the end of
                the <prgn>build</prgn> target, as suggested above, it
                should be removed as the first action that
                <prgn>clean</prgn> performs, so that running
                <prgn>build</prgn> again after an interrupted
                <prgn>clean</prgn> doesn't think that everything is
                already done.
              </p>

              <p>
                The <prgn>clean</prgn> target may need to be
                invoked as root if <prgn>binary</prgn> has been
                invoked since the last <prgn>clean</prgn>, or if
                <prgn>build</prgn> has been invoked as root (since
                <prgn>build</prgn> may create directories, for
                example).
              </p>
            </item>

            <tag><tt>get-orig-source</tt> (optional)</tag>
            <item>

              <p>
                This target fetches the most recent version of the
                original source package from a canonical archive site
                (via FTP or WWW, for example), does any necessary
                rearrangement to turn it into the original source
                tar file format described below, and leaves it in the
                current directory.
              </p>

              <p>
                This target may be invoked in any directory, and
                should take care to clean up any temporary files it
                may have left.
              </p>

              <p>
                This target is optional, but providing it if
                possible is a good idea.
              </p>
            </item>
          </taglist>

        <p>
          The <prgn>build</prgn>, <prgn>binary</prgn> and
          <prgn>clean</prgn> targets must be invoked with the current
          directory being the package's top-level directory.
        </p>


        <p>
          Additional targets may exist in <tt>debian/rules</tt>,
          either as published or undocumented interfaces or for the
          package's internal use.
        </p>

        <p>
          The architectures we build on and build for are determined
          by <prgn>make</prgn> variables using the utility
          <prgn>dpkg-architecture</prgn>.  You can determine the
          Debian architecture and the GNU style architecture
          specification string for the build machine (the machine type
          we are building on) as well as for the host machine (the
          machine type we are building for).  Here is a list of
          supported <prgn>make</prgn> variables:
          <list compact="compact">
            <item>
              <p><tt>DEB_*_ARCH</tt> (the Debian architecture)</p>
            </item>
            <item>
              <p><tt>DEB_*_GNU_TYPE</tt> (the GNU style architecture
                specification string)</p>
            </item>
            <item>
              <p><tt>DEB_*_GNU_CPU</tt> (the CPU part of
              <tt>DEB_*_GNU_TYPE</tt>)</p>
            </item>
            <item>
              <p><tt>DEB_*_GNU_SYSTEM</tt> (the System part of
                <tt>DEB_*_GNU_TYPE</tt>)</p>
          </list>
          where <tt>*</tt> is either <tt>BUILD</tt> for specification of
          the build machine or <tt>HOST</tt> for specification of the
          host machine.
        </p>

        <p>
          Backward compatibility can be provided in the rules file
          by setting the needed variables to suitable default
          values; please refer to the documentation of
          <prgn>dpkg-architecture</prgn> for details.
        </p>

        <p>
          It is important to understand that the <tt>DEB_*_ARCH</tt>
          string only determines which Debian architecture we are
          building on or for. It should not be used to get the CPU
          or system information; the GNU style variables should be
          used for that.
        </p>
      </sect>

      <sect id="dpkgchangelog"><heading><tt>debian/changelog</tt>
        </heading>

        <p>
          This file records the changes to the Debian-specific parts of the
          package
          <footnote>
            <p>
              Though there is nothing stopping an author who is also
              the Debian maintainer from using it for all their
              changes, it will have to be renamed if the Debian and
              upstream maintainers become different people.  In such a
              case, however, it might be better to maintain the
              package as a non-native package.
            </p>
          </footnote>.
        </p>

        <p>
          It has a special format which allows the package building
          tools to discover which version of the package is being
          built and find out other release-specific information.
        </p>

        <p>
          That format is a series of entries like this:
          <example compact="compact">
<var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>

  * <var>change details</var>
    <var>more change details</var>
  * <var>even more change details</var>

 -- <var>maintainer name</var> &lt;<var>email address</var>&gt;  <var>date</var>
          </example>
        </p>

        <p>
          <var>package</var> and <var>version</var> are the source
          package name and version number.
        </p>

        <p>
          <var>distribution(s)</var> lists the distributions where
          this version should be installed when it is uploaded - it
          is copied to the <tt>Distribution</tt> field in the
          <tt>.changes</tt> file.  See <ref id="f-Distribution">.
        </p>

        <p>
          <var>urgency</var> is the value for the <tt>Urgency</tt>
          field in the <tt>.changes</tt> file for the upload. It is
          not possible to specify an urgency containing commas; commas
          are used to separate
          <tt><var>keyword</var>=<var>value</var></tt> settings in the
          <prgn>dpkg</prgn> changelog format (though there is
          currently only one useful <var>keyword</var>,
          <tt>urgency</tt>).
          <footnote>
            <p>
              Usual urgency values are <tt>low</tt>, <tt>medium</tt>,
              <tt>high</tt> and <tt>critical</tt>.  They have an
              effect on how quickly a package will be considered for
              inclusion into the <tt>testing</tt> distribution, and
              give an indication of the importance of any fixes
              included in this upload.
            </p>
          </footnote>
        </p>

        <p>
          The change details may in fact be any series of lines
          starting with at least two spaces, but conventionally each
          change starts with an asterisk and a separating space and
          continuation lines are indented so as to bring them in
          line with the start of the text above.  Blank lines may be
          used here to separate groups of changes, if desired.
        </p>

        <p>
          If this upload resolves bugs recorded in the Bug Tracking
          System (BTS), they may be automatically closed on the
          inclusion of this package into the Debian archive by
          including the string: <tt>closes: Bug#<var>nnnnn</var></tt>
          in the change details.
          <footnote>
            <p>
              To be precise, the string should match the following
              Perl regular expression:
              <example>
/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>), or in
              the case of an NMU, marked as fixed.
            </p>
          </footnote>
        </p>

        <p>
          The maintainer name and email address used in the changelog
          should be the details of the person uploading <em>this</em>
          version.  They are <em>not</em> necessarily those of the
          usual package maintainer.  The information here will be
          copied to the <tt>Changed-By</tt> field in the
          <tt>.changes</tt> file, and then later used to send an
          acknowledgement when the upload has been installed.
        </p>

        <p>
          The <var>date</var> should be in RFC822 format
          <footnote>
            <p>
              This is generated by the <prgn>822-date</prgn>
              program.
            </p>
          </footnote>; it should include the time zone specified
          numerically, with the time zone name or abbreviation
          optionally present as a comment in parentheses.
        </p>

        <p>
          The first `title' line with the package name should start
          at the left hand margin; the `trailer' line with the
          maintainer and date details should be preceded by exactly
          one space.  The maintainer details and the date must be
          separated by exactly two spaces.
        </p>

        <sect1><heading>Defining alternative changelog formats</heading>

          <p>
            It is possible to use a different format to the standard
            one, by providing a parser for the format you wish to
            use.
          </p>
          <p>
            A changelog parser must not interact with the user at
            all.
          </p>
        </sect1>
      </sect>

      <sect id="srcsubstvars"><heading><tt>debian/substvars</tt>
          and variable substitutions      </heading>

        <p>
          When <prgn>dpkg-gencontrol</prgn>,
          <prgn>dpkg-genchanges</prgn> and <prgn>dpkg-source</prgn>
          generate control files they perform variable substitutions
          on their output just before writing it.  Variable
          substitutions have the form <tt>${<var>variable</var>}</tt>.
          The optional file <tt>debian/substvars</tt> contains
          variable substitutions to be used; variables can also be set
          directly from <tt>debian/rules</tt> using the <tt>-V</tt>
          option to the source packaging commands, and certain
          predefined variables are also available.
        </p>

        <p>
          The <tt>debian/substvars</tt> file is usually generated and
          modified dynamically by <tt>debian/rules</tt> targets; in
          this case it must be removed by the <prgn>clean</prgn>
          target.
        </p>

        <p>
          See <manref name="dpkg-source" section="1"> for full
          details about source variable substitutions, including the
          format of <tt>debian/substvars</tt>.</p>
      </sect>

      <sect id="debianfiles"><heading><tt>debian/files</tt>
        </heading>

        <p>
          This file is not a permanent part of the source tree; it
          is used while building packages to record which files are
          being generated.  <prgn>dpkg-genchanges</prgn> uses it
          when it generates a <tt>.changes</tt> file.
        </p>

        <p>
          It should not exist in a shipped source package, and so it
          (and any backup files or temporary files such as
          <tt>files.new</tt>
          <footnote>
            <p>
              <tt>files.new</tt> is used as a temporary file by
              <prgn>dpkg-gencontrol</prgn> and
              <prgn>dpkg-distaddfile</prgn> - they write a new
              version of <tt>files</tt> here before renaming it,
              to avoid leaving a corrupted copy if an error
              occurs
            </p>
          </footnote>) should be removed by the
          <prgn>clean</prgn> target.  It may also be wise to
          ensure a fresh start by emptying or removing it at the
          start of the <prgn>binary</prgn> target.
        </p>

        <p>
          When <prgn>dpkg-gencontrol</prgn> is run for a binary
          package, it adds an entry to <tt>debian/files</tt> for the
          <tt>.deb</tt> file that will be created when <tt>dpkg-deb
          --build</tt> is run for that binary package.  So for most
          packages all that needs to be done with this file is to
          delete it in the <prgn>clean</prgn> target.
        </p>

        <p>
          If a package upload includes files besides the source
          package and any binary packages whose control files were
          made with <prgn>dpkg-gencontrol</prgn> then they should be
          placed in the parent of the package's top-level directory
          and <prgn>dpkg-distaddfile</prgn> should be called to add
          the file to the list in <tt>debian/files</tt>.</p>
      </sect>

      <sect id="restrictions"><heading>Restrictions on objects in source packages
        </heading>

        <p>
          The source package may not contain any hard links
          <footnote>
            <p>
              This is not currently detected when building source
              packages, but only when extracting
              them.
            </p>
            <p>
              Hard links may be permitted at some point in the
              future, but would require a fair amount of
              work.
            </p>
          </footnote>, device special files, sockets or setuid or
          setgid files.
          <footnote>
            <p>
              Setgid directories are allowed.
            </p>
          </footnote>
        </p>
      </sect>
      <sect id="descriptions"><heading>Descriptions of packages - the
          <tt>Description</tt> field </heading>

        <p>
          The description is intended to describe the program to a user
          who has never met it before so that they know whether they
          want to install it.  It should also give information about the
          significant dependencies and conflicts between this package
          and others, so that the user knows why these dependencies and
          conflicts have been declared.
        </p>

        <sect1><heading>Notes about writing descriptions
          </heading>

          <p>
            The single line synopsis should be kept brief - certainly
            under 80 characters.
          </p>

          <p>
            Do not include the package name in the synopsis line.  The
            display software knows how to display this already, and you
            do not need to state it.  Remember that in many situations
            the user may only see the synopsis line - make it as
            informative as you can.
          </p>

          <p>
            Do not try to continue the single line synopsis into the
            extended description.  This will not work correctly when
            the full description is displayed, and makes no sense
            where only the summary (the single line synopsis) is
            available.
          </p>

          <p>
            The extended description should describe what the package
            does and how it relates to the rest of the system (in terms
            of, for example, which subsystem it is which part of).
          </p>

          <p>
            The description field needs to make sense to anyone, even
            people who have no idea about any of the things the
            package deals with.
            <footnote>
              <p>
                The blurb that comes with a program in its
                announcements and/or <prgn>README</prgn> files is
                rarely suitable for use in a description.  It is
                usually aimed at people who are already in the
                community where the package is used.
              </p>
            </footnote>
          </p>

          <p>
            Put important information first, both in the synopsis and
            extended description.  Sometimes only the first part of the
            synopsis or of the description will be displayed.  You can
            assume that there will usually be a way to see the whole
            extended description.
          </p>

          <p>
            You may include information about dependencies and so forth
            in the extended description, if you wish.
          </p>

          <p>
            Do not use tab characters.  Their effect is not predictable.
          </p>

        </sect1>
      </sect>
    </chapt>


    <chapt id="maintainerscripts"><heading>Package maintainer scripts
        and installation procedure
      </heading>

      <sect><heading>Introduction to package maintainer scripts
        </heading>

        <p>
          It is possible to supply scripts as part of a package which
          the package management system will run for you when your
          package is installed, upgraded or removed.
        </p>

        <p>
          These scripts are the files <prgn>preinst</prgn>,
          <prgn>postinst</prgn>, <prgn>prerm</prgn> and <prgn>postrm</prgn> in the
          control area of the package.  They must be proper executable
          files; if they are scripts (which is recommended), they must
          start with the usual <tt>#!</tt> convention.  They should be
          readable and executable by anyone, and not world-writable.
        </p>

        <p>
          The package management system looks at the exit status from
          these scripts.  It is important that they exit with a
          non-zero status if there is an error, so that the package
          management system can stop its processing.  For shell
          scripts this means that you <em>almost always</em> need to
          use <tt>set -e</tt> (this is usually true when writing shell
          scripts, in fact).  It is also important, of course, that
          they don't exit with a non-zero status if everything went
          well.
        </p>

        <p>
          When a package is upgraded a combination of the scripts from
          the old and new packages is called during the upgrade
          procedure.  If your scripts are going to be at all
          complicated you need to be aware of this, and may need to
          check the arguments to your scripts.
        </p>

        <p>
          Broadly speaking the <prgn>preinst</prgn> is called before
          (a particular version of) a package is installed, and the
          <prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
          before (a version of) a package is removed and the
          <prgn>postrm</prgn> afterwards.
        </p>

        <p>
          Programs called from maintainer scripts should not normally
          have a path prepended to them. Before installation is
          started, the package management system checks to see if the
          programs <prgn>ldconfig</prgn>,
          <prgn>start-stop-daemon</prgn>, <prgn>install-info</prgn>,
          and <prgn>update-rc.d</prgn> can be found via the
          <tt>PATH</tt> environment variable. Those programs, and any
          other program that one would expect to be on the
          <tt>PATH</tt>, should thus be invoked without an absolute
          pathname. Maintainer scripts should also not reset the
          <tt>PATH</tt>, though they might choose to modify it by
          prepending or appending package-specific directories. These
          considerations really apply to all shell scripts.</p>
      </sect>

      <sect>
        <heading>Maintainer scripts Idempotency</heading>

        <p>
          It is necessary for the error recovery procedures that the
          scripts be idempotent.  This means that if it is run
          successfully, and then it is called again, it doesn't bomb
          out or cause any harm, but just ensures that everything is
          the way it ought to be.  If the first call failed, or
          aborted half way through for some reason, the second call
          should merely do the things that were left undone the first
          time, if any, and exit with a success status if everything
          is OK.
          <footnote> 
            <p>
              This is so that if an error occurs, the user interrupts
              <prgn>dpkg</prgn> or some other unforeseen circumstance
              happens you don't leave the user with a badly-broken
              package when <prgn>dpkg</prgn> attempts to repeat the
              action.
            </p>
          </footnote>
        </p>
      </sect>

      <sect>
        <heading>Controlling terminal for maintainer scripts</heading>

        <p>
          The maintainer scripts are guaranteed to run with a
          controlling terminal and can interact with the user.
          If they need to prompt for passwords, do full-screen
          interaction or something similar you should do these
          things to and from <tt>/dev/tty</tt>, since
          <prgn>dpkg</prgn> will at some point redirect scripts'
          standard input and output so that it can log the
          installation process.  Likewise, because these scripts
          may be executed with standard output redirected into a
          pipe for logging purposes, Perl scripts should set
          unbuffered output by setting <tt>$|=1</tt> so that the
          output is printed immediately rather than being
          buffered.
        </p>

        <p>
          Each script should return a zero exit status for
          success, or a nonzero one for failure.
        </p>
      </sect>

      <sect id="mscriptsinstact"><heading>Summary of ways maintainer
          scripts are called
        </heading>

        <p>
          <list compact="compact">
            <item>
              <p><var>new-preinst</var> <tt>install</tt></p>
            </item>
            <item>
              <p><var>new-preinst</var> <tt>install</tt>
                <var>old-version</var></p>
            </item>
            <item>
              <p><var>new-preinst</var> <tt>upgrade</tt>
                <var>old-version</var></p>
            </item>
            <item>
              <p><var>old-preinst</var> <tt>abort-upgrade</tt>
                <var>new-version</var>
              </p>
            </item>
          </list>

        <p>
          <list compact="compact">
            <item>
              <p><var>postinst</var> <tt>configure</tt>
                <var>most-recently-configured-version</var></p>
            </item>
            <item>
              <p><var>old-postinst</var> <tt>abort-upgrade</tt>
                <var>new-version</var></p>
            </item>
            <item>
              <p><var>conflictor's-postinst</var> <tt>abort-remove</tt>
                <tt>in-favour</tt> <var>package</var>
                <var>new-version</var></p>
            </item>
            <item>
              <p>
                <var>deconfigured's-postinst</var>
                <tt>abort-deconfigure</tt> <tt>in-favour</tt>
                <var>failed-install-package</var> <var>version</var>
                <tt>removing</tt> <var>conflicting-package</var>
                <var>version</var>
              </p>
            </item>
          </list>

        <p>
          <list compact="compact">
            <item>
              <p><var>prerm</var> <tt>remove</tt></p>
            </item>
            <item>
              <p><var>old-prerm</var> <tt>upgrade</tt>
                <var>new-version</var></p>
            </item>
            <item>
              <p><var>new-prerm</var> <tt>failed-upgrade</tt>
                <var>old-version</var></p>
            </item>
            <item>
              <p><var>conflictor's-prerm</var> <tt>remove</tt>
                <tt>in-favour</tt> <var>package</var>
                <var>new-version</var></p>
            </item>
            <item>
              <p>
                <var>deconfigured's-prerm</var> <tt>deconfigure</tt>
                <tt>in-favour</tt> <var>package-being-installed</var>
                <var>version</var> <tt>removing</tt>
                <var>conflicting-package</var>
                <var>version</var>
              </p>
            </item>
          </list>

        <p>
          <list compact="compact">
            <item>
              <p><var>postrm</var> <tt>remove</tt></p>
            </item>
            <item>
              <p><var>postrm</var> <tt>purge</tt></p>
            </item>
            <item>
              <p>
                <var>old-postrm</var> <tt>upgrade</tt>
                <var>new-version</var></p>
            </item>
            <item>
              <p><var>new-postrm</var> <tt>failed-upgrade</tt>
                <var>old-version</var></p>
            </item>
            <item>
              <p><var>new-postrm</var> <tt>abort-install</tt></p>
            </item>
            <item>
              <p><var>new-postrm</var> <tt>abort-install</tt>
                <var>old-version</var></p>
            </item>
            <item>
              <p><var>new-postrm</var> <tt>abort-upgrade</tt>
                <var>old-version</var></p>
            </item>
            <item>
              <p>
                <var>disappearer's-postrm</var> <tt>disappear</tt>
                <var>overwriter</var>
                <var>overwriter-version</var></p></item>
          </list>
        </p>


      <sect id="unpackphase"><heading>Details of unpack phase of
          installation or upgrade
        </heading>

        <p>
          The procedure on installation/upgrade/overwrite/disappear
          (i.e., when running <tt>dpkg --unpack</tt>, or the unpack
          stage of <tt>dpkg --install</tt>) is as follows.  In each
          case, if a major error occurs (unless listed below) the
          actions are, in general, run backwards - this means that the
          maintainer scripts are run with different arguments in
          reverse order.  These are the `error unwind' calls listed
          below.

          <enumlist>
            <item>
              <p>
                <enumlist>
                  <item>
                    <p>If a version of the package is already
                      installed, call
                      <example compact="compact">
<var>old-prerm</var> upgrade <var>new-version</var>
                      </example></p>
                  </item>
                  <item>
                    <p>
                      If the script runs but exits with a non-zero
                      exit status, <prgn>dpkg</prgn> will attempt:
                      <example compact="compact">
<var>new-prerm</var> failed-upgrade <var>old-version</var>
                      </example>
                      Error unwind, for both the above cases:
                      <example compact="compact">
<var>old-postinst</var> abort-upgrade <var>new-version</var>
                      </example>
                    </p>
                  </item>
                </enumlist>
              </p>
            </item>
            <item>
              <p>If a `conflicting' package is being removed at the same time:
                <enumlist>
                  <item>
                    <p>
                      If any packages depended on that conflicting
                      package and <tt>--auto-deconfigure</tt> is
                      specified, call, for each such package:
                      <example compact="compact">
<var>deconfigured's-prerm</var> deconfigure \
  in-favour <var>package-being-installed</var> <var>version</var> \
    removing <var>conflicting-package</var> <var>version</var>
                      </example>
                      Error unwind:
                      <example compact="compact">
<var>deconfigured's-postinst</var> abort-deconfigure \
  in-favour <var>package-being-installed-but-failed</var> <var>version</var> \
    removing <var>conflicting-package</var> <var>version</var>
                      </example>
                      The deconfigured packages are marked as
                      requiring configuration, so that if
                      <tt>--install</tt> is used they will be
                      configured again if possible.</p>
                  </item>
                  <item>
                    <p>To prepare for removal of the conflicting package, call:
                      <example compact="compact">
<var>conflictor's-prerm</var> remove \
  in-favour <var>package</var> <var>new-version</var>
                      </example>
                      Error unwind:
                      <example compact="compact">
<var>conflictor's-postinst</var> abort-remove \
  in-favour <var>package</var> <var>new-version</var>
                      </example>
                    </p>
                  </item>
                </enumlist>
              </p>
            </item>
            <item>
              <p>
                <enumlist>
                  <item>
                    <p>If the package is being upgraded, call:
                      <example compact="compact">
<var>new-preinst</var> upgrade <var>old-version</var>
                      </example></p>
                  </item>
                  <item>
                    <p>
                      Otherwise, if the package had some configuration
                      files from a previous version installed (i.e., it
                      is in the `configuration files only' state):
                      <example compact="compact">
<var>new-preinst</var> install <var>old-version</var>
                      </example></p>

                  <item>
                    <p>Otherwise (i.e., the package was completely purged):
                      <example compact="compact">
<var>new-preinst</var> install
                      </example>
                      Error unwind actions, respectively:
                      <example compact="compact">
<var>new-postrm</var> abort-upgrade <var>old-version</var>
<var>new-postrm</var> abort-install <var>old-version</var>
<var>new-postrm</var> abort-install
                      </example>
                    </p>
                  </item>
                </enumlist>
              </p>
            </item>
            <item>
              <p>
                The new package's files are unpacked, overwriting any
                that may be on the system already, for example any
                from the old version of the same package or from
                another package.  Backups of the old files are kept
                temporarily, and if anything goes wrong the package
                management system will attempt to put them back as
                part of the error unwind.
              </p>

              <p>
                It is an error for a package to contains files which
                are on the system in another package, unless
                <tt>Replaces</tt> is used (see <ref id="replaces">).
                <!--
                The following paragraph is not currently the case:
                Currently the <tt>- - force-overwrite</tt> flag is
                enabled, downgrading it to a warning, but this may not
                always be the case.
                -->
              </p>

              <p>
                It is a more serious error for a package to contain a
                plain file or other kind of non-directory where another
                package has a directory (again, unless
                <tt>Replaces</tt> is used).  This error can be
                overridden if desired using
                <tt>--force-overwrite-dir</tt>, but this is not
                advisable.
              </p>

              <p>
                Packages which overwrite each other's files produce
                behavior which, though deterministic, is hard for the
                system administrator to understand.  It can easily
                lead to `missing' programs if, for example, a package
                is installed which overwrites a file from another
                package, and is then removed again.
                <footnote>
                  <p>
                    Part of the problem is due to what is arguably a
                    bug in <prgn>dpkg</prgn>.
                  </p>
                </footnote>
              </p>

              <p>
                A directory will never be replaced by a symbolic link
                to a directory or vice versa; instead, the existing
                state (symlink or not) will be left alone and
                <prgn>dpkg</prgn> will follow the symlink if there is
                one.</p>
            </item>

            <item>
              <p>
                <enumlist>
                  <item>
                    <p>If the package is being upgraded, call
                      <example compact="compact">
<var>old-postrm</var> upgrade <var>new-version</var>
                      </example>
                    </p>
                  </item>
                  <item>
                    <p>If this fails, <prgn>dpkg</prgn> will attempt:
                      <example compact="compact">
<var>new-postrm</var> failed-upgrade <var>old-version</var>
                      </example>
                      Error unwind, for both cases:
                      <example compact="compact">
<var>old-preinst</var> abort-upgrade <var>new-version</var>
                      </example>
                    </p>
                  </item>
                </enumlist>
              </p>
              <p>
                This is the point of no return - if
                <prgn>dpkg</prgn> gets this far, it won't back off
                past this point if an error occurs.  This will
                leave the package in a fairly bad state, which
                will require a successful re-installation to clear
                up, but it's when <prgn>dpkg</prgn> starts doing
                things that are irreversible.
              </p>
            </item>
            <item>
              <p>
                Any files which were in the old version of the package
                but not in the new are removed.</p>
            </item>
            <item>
              <p>The new file list replaces the old.</p>
            </item>
            <item>
              <p>The new maintainer scripts replace the old.</p>
            </item>

            <item>
              <p>Any packages all of whose files have been overwritten during the
                installation, and which aren't required for
                dependencies, are considered to have been removed.
                For each such package
                <enumlist>
                  <item>
                    <p><prgn>dpkg</prgn> calls:
                      <example compact="compact">
<var>disappearer's-postrm</var> disappear \
  <var>overwriter</var> <var>overwriter-version</var>
                      </example>
                    </p>
                  </item>
                  <item>
                    <p>The package's maintainer scripts are removed.
                    </p>
                  </item>
                  <item>
                    <p>
                      It is noted in the status database as being in a
                      sane state, namely not installed (any conffiles
                      it may have are ignored, rather than being
                      removed by <prgn>dpkg</prgn>).  Note that
                      disappearing packages do not have their prerm
                      called, because <prgn>dpkg</prgn> doesn't know
                      in advance that the package is going to
                      vanish.
                    </p>
                  </item>
                </enumlist>
              </p>
            </item>
            <item>
              <p>
                Any files in the package we're unpacking that are also
                listed in the file lists of other packages are removed
                from those lists.  (This will lobotomize the file list
                of the `conflicting' package if there is one.)
              </p>
            </item>
            <item>
              <p>
                The backup files made during installation, above, are
                deleted.
              </p>
            </item>

            <item>
              <p>
                The new package's status is now sane, and recorded as
                `unpacked'.
              </p>

              <p>
                Here is another point of no return - if the
                conflicting package's removal fails we do not unwind
                the rest of the installation; the conflicting package
                is left in a half-removed limbo.
              </p>
            </item>

            <item>
              <p>
                If there was a conflicting package we go and do the
                removal actions (described below), starting with the
                removal of the conflicting package's files (any that
                are also in the package being installed have already
                been removed from the conflicting package's file list,
                and so do not get removed now).
              </p>
            </item>
          </enumlist>
        </p>
      </sect>

      <sect id="configdetails"><heading>Details of configuration</heading>

        <p>
          When we configure a package (this happens with <tt>dpkg
            --install</tt> and <tt>dpkg --configure</tt>), we first
          update any <tt>conffile</tt>s and then call:
          <example compact="compact">
<var>postinst</var> configure <var>most-recently-configured-version</var>
          </example>
        </p>

        <p>
          No attempt is made to unwind after errors during
          configuration.
        </p>

        <p>
          If there is no most recently configured version
          <prgn>dpkg</prgn> will pass a null argument; older versions
          of dpkg may pass <tt>&lt;unknown&gt;</tt> (including the
          angle brackets) in this case.  Even older ones do not pass a
          second argument at all, under any circumstances.
        </p>
      </sect>

      <sect id="removedetails"><heading>Details of removal and/or
      configuration purging</heading>

        <p>
          <enumlist>
            <item>
              <p>
                <example compact="compact">
<var>prerm</var> remove
                </example>
              </p>
            </item>
            <item>
              <p>
                The package's files are removed (except <tt>conffile</tt>s).
              </p>
            </item>
            <item>
              <p>
                <example compact="compact">
<var>postrm</var> remove
                </example>
              </p>
            </item>
            <item>
              <p>
                All the maintainer scripts except the <prgn>postrm</prgn>
                are removed.
              </p>

              <p>
                If we aren't purging the package we stop here.  Note
                that packages which have no <prgn>postrm</prgn> and no
                <tt>conffile</tt>s are automatically purged when
                removed, as there is no difference except for the
                <prgn>dpkg</prgn> status.</p>
            </item>
            <item>
              <p>
                The <tt>conffile</tt>s and any backup files
                (<tt>~</tt>-files, <tt>#*#</tt> files,
                <tt>%</tt>-files, <tt>.dpkg-{old,new,tmp}</tt>, etc.)
                are removed.</p>
            </item>
            <item>
              <p>
                <example compact="compact">
<var>postrm</var> purge
                </example>
              </p>
            </item>
            <item>
              <p>The package's file list is removed.</p>
            </item>
          </enumlist>
          No attempt is made to unwind after errors during
          removal.
        </p>
      </sect>
    </chapt>


    <chapt id="relationships"><heading>Declaring relationships between
        packages</heading>

      <p>
        Packages can declare in their control file that they have
        certain relationships to other packages - for example, that
        they may not be installed at the same time as certain other
        packages, and/or that they depend on the presence of others,
        or that they should overwrite files in certain other packages
        if present.
      </p>

      <p>
        This is done using the <tt>Depends</tt>, <tt>Pre-Depends</tt>,
        <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
        <tt>Conflicts</tt>, <tt>Provides</tt> and <tt>Replaces</tt>
        control file fields.
      </p>

      <p>
        Source packages may declare relationships to binary packages,
        saying that they require certain binary packages to be
        installed or absent at the time of building the package.
      </p>

      <p>
        This is done using the <tt>Build-Depends</tt>,
        <tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt> and
        <tt>Build-Conflicts-Indep</tt> control file fields.
      </p>

      <sect id="depsyntax"><heading>Syntax of relationship fields
        </heading>

        <p>
          These fields all have a uniform syntax.  They are a list of
          package names separated by commas.
        </p>

        <p>
          In the <tt>Depends</tt>, <tt>Recommends</tt>,
          <tt>Suggests</tt>, <tt>Pre-Depends</tt>,
          <tt>Build-Depends</tt> and <tt>Build-Depends-Indep</tt>
          control file fields of the package, which declare
          dependencies on other packages, the package names listed may
          also include lists of alternative package names, separated
          by vertical bar (pipe) symbols <tt>|</tt>.  In such a case,
          if any one of the alternative packages is installed, that
          part of the dependency is considered to be satisfied.
        </p>

        <p>
          All of the fields except for <tt>Provides</tt> may restrict
          their applicability to particular versions of each named
          package.  This is done in parentheses after each individual
          package name; the parentheses should contain a relation from
          the list below followed by a version number, in the format
          described in <ref id="versions">.
        </p>

        <p>
          The relations allowed are <tt>&lt;&lt;</tt>, <tt>&lt;=</tt>,
          <tt>=</tt>, <tt>&gt;=</tt> and <tt>&gt;&gt;</tt> for
          strictly earlier, earlier or equal, exactly equal, later or
          equal and strictly later, respectively.  The deprecated
          forms <tt>&lt;</tt> and <tt>&gt;</tt> were used to mean
          earlier/later or equal, rather than strictly earlier/later,
          so they should not appear in new packages (though
          <prgn>dpkg</prgn> still supports them).
        </p>

        <p>
          Whitespace may appear at any point in the version
          specification subject to the rules in <ref
          id="controlsyntax">, and must appear where it's necessary to
          disambiguate; it is not otherwise significant.  For
          consistency and in case of future changes to
          <prgn>dpkg</prgn> it is recommended that a single space be
          used after a version relationship and before a version
          number; it is also conventional to put a single space after
          each comma, on either side of each vertical bar, and before
          each open parenthesis.
        </p>

        <p>
          For example, a list of dependencies might appear as:
          <example compact="compact">
Package: mutt
Version: 1.3.17-1
Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
          </example>
        </p>

        <p>
          All fields that specify build-time relationships
          (<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
          <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>)
          may be restricted to a certain set of architectures.  This
          is indicated in brackets after each individual package name and
          the optional version specification.  The brackets enclose a
          list of Debian architecture names separated by whitespace.
          Exclamation marks may be prepended to each of the names.
          (It is not permitted for some names to be prepended with
          exclamation marks and others not.) If the current Debian
          host architecture is not in this list and there are no
          exclamation marks in the list, or it is in the list with a
          prepended exclamation mark, the package name and the
          associated version specification are ignored completely for
          the purposes of defining the relationships.
        </p>

        <p>
          For example:
          <example compact="compact">
Source: glibc
Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
  hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
          </example>
        </p>

        <p>
          Note that the binary package relationship fields such as
          <tt>Depends</tt> appear in one of the binary package
          sections of the control file, whereas the build-time
          relationships such as <tt>Build-Depends</tt> appear in the
          source package section of the control file (which is the
          first section).
        </p>
      </sect>

      <sect>
        <heading>Binary Dependencies - <tt>Depends</tt>,
          <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
          <tt>Pre-Depends</tt>
        </heading>

        <p>
          These five fields are used to declare a dependency
          relationship by one package on another.  Except for
          <tt>Enhances</tt>, they appear in the depending (binary)
          package's control file.  (<tt>Enhances</tt> appears in the
          recommending package's control file.)
        </p>

        <p>
          A <tt>Depends</tt> field takes effect <em>only</em> when a
          package is to be configured.  It does not prevent a package
          being on the system in an unconfigured state while its
          dependencies are unsatisfied, and it is possible to replace
          a package whose dependencies are satisfied and which is
          properly installed with a different version whose
          dependencies are not and cannot be satisfied; when this is
          done the depending package will be left unconfigured (since
          attempts to configure it will give errors) and will not
          function properly.  If it is necessary, a
          <tt>Pre-Depends</tt> field can be used, which has a partial
          effect even when a package is being unpacked, as explained
          in detail below.  (The other three dependency fields,
          <tt>Recommends</tt>, <tt>Suggests</tt> and
          <tt>Enhances</tt>, are only used by the various front-ends
          to <prgn>dpkg</prgn> such as <prgn>dselect</prgn>.)
        </p>

        <p>
          For this reason packages in an installation run are usually
          all unpacked first and all configured later; this gives
          later versions of packages with dependencies on later
          versions of other packages the opportunity to have their
          dependencies satisfied.
        </p>

        <p>
          The <tt>Depends</tt> field thus allows package maintainers
          to impose an order in which packages should be configured.
        </p>

        <p>
          The meaning of the five dependency fields is as follows:
          <taglist>
            <tag><tt>Depends</tt></tag>
            <item>

              <p>
                This declares an absolute dependency.  A package will
                not be configured unless all of the packages listed in
                its <tt>Depends</tt> field have been correctly
                configured.
              </p>

              <p>
                The <tt>Depends</tt> field should be used if the
                depended-on package is required for the depending
                package to provide a significant amount of
                functionality.
              </p>
              <p>
                The <tt>Depends</tt> field should also be used if the
                <prgn>postinst</prgn>, <prgn>prerm</prgn> or
                <prgn>postrm</prgn> scripts require the package to be
                present in order to run.  Note, however, that the
                <prgn>postrm</prgn> cannot rely on any non-essential
                packages to be present during the <tt>purge</tt>
                phase.
            </item>

            <tag><tt>Recommends</tt></tag>
            <item>
              <p>This declares a strong, but not absolute, dependency.
              </p>

              <p>
                The <tt>Recommends</tt> field should list packages
                that would be found together with this one in all but
                unusual installations.</p>
            </item>

            <tag><tt>Suggests</tt></tag>
            <item>

              <p>
                This is used to declare that one package may be more
                useful with one or more others.  Using this field
                tells the packaging system and the user that the
                listed packages are related to this one and can
                perhaps enhance its usefulness, but that installing
                this one without them is perfectly reasonable.
              </p>
            </item>

            <tag><tt>Enhances</tt></tag>
            <item>
              <p>
                This field is similar to Suggests but works in the
                opposite direction. It is used to declare that a
                package can enhance the functionality of another
                package.
              </p>
            </item>

            <tag><tt>Pre-Depends</tt></tag>
            <item>

              <p>
                This field is like <tt>Depends</tt>, except that it
                also forces <prgn>dpkg</prgn> to complete installation
                of the packages named before even starting the
                installation of the package which declares the
                pre-dependency, as follows:
              </p>

              <p>
                When a package declaring a pre-dependency is about to
                be <em>unpacked</em> the pre-dependency can be
                satisfied if the depended-on package is either fully
                configured, <em>or even if</em> the depended-on
                package(s) are only unpacked or half-configured,
                provided that they have been configured correctly at
                some point in the past (and not removed or partially
                removed since).  In this case, both the
                previously-configured and currently unpacked or
                half-configured versions must satisfy any version
                clause in the <tt>Pre-Depends</tt> field.
              </p>

              <p>
                When the package declaring a pre-dependency is about
                to be <em>configured</em>, the pre-dependency will be
                treated as a normal <tt>Depends</tt>, that is, it will
                be considered satisfied only if the depended-on
                package has been correctly configured.
              </p>

              <p>
                <tt>Pre-Depends</tt> should be used sparingly,
                preferably only by packages whose premature upgrade or
                installation would hamper the ability of the system to
                continue with any upgrade that might be in progress.
              </p>

              <p>
                <tt>Pre-Depends</tt> are also required if the
                <prgn>preinst</prgn> script depends on the named
                package.  It is best to avoid this situation if
                possible.
            </item>
          </taglist>
        </p>
        <p>
          When selecting which level of dependency to use you should
          consider how important the depended-on package is to the
          functionality of the one declaring the dependency.  Some
          packages are composed of components of varying degrees of
          importance.  Such a package should list using
          <tt>Depends</tt> the package(s) which are required by the
          more important components.  The other components'
          requirements may be mentioned as Suggestions or
          Recommendations, as appropriate to the components' relative
          importance.
        </p>


      <sect id="conflicts"><heading>Conflicting binary packages -
           <tt>Conflicts</tt></heading>

        <p>
          When one binary package declares a conflict with another
          using a <tt>Conflicts</tt> field, <prgn>dpkg</prgn> will
          refuse to allow them to be installed on the system at the
          same time.
        </p>

        <p>
          If one package is to be installed, the other must be removed
          first - if the package being installed is marked as
          replacing (see <ref id="replaces">) the one on the system,
          or the one on the system is marked as deselected, or both
          packages are marked <tt>Essential</tt>, then
          <prgn>dpkg</prgn> will automatically remove the package
          which is causing the conflict, otherwise it will halt the
          installation of the new package with an error.  This
          mechanism is specifically designed to produce an error when
          the installed package is <tt>Essential</tt>, but the new
          package is not.
        </p>

        <p>
          A package will not cause a conflict merely because its
          configuration files are still installed; it must be at least
          half-installed.
        </p>

        <p>
          A special exception is made for packages which declare a
          conflict with their own package name, or with a virtual
          package which they provide (see below): this does not
          prevent their installation, and allows a package to conflict
          with others providing a replacement for it.  You use this
          feature when you want the package in question to be the only
          package providing some feature.
        </p>

        <p>
          A <tt>Conflicts</tt> entry should almost never have an
          `earlier than' version clause.  This would prevent
          <prgn>dpkg</prgn> from upgrading or installing the package
          which declared such a conflict until the upgrade or removal
          of the conflicted-with package had been completed.
        </p>
      </sect>

      <sect id="virtual"><heading>Virtual packages - <tt>Provides</tt>
        </heading>

        <p>
          As well as the names of actual (`concrete') packages, the
          package relationship fields <tt>Depends</tt>,
          <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
          <tt>Pre-Depends</tt>, <tt>Conflicts</tt>,
          <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
          <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>
          may mention `virtual packages'.
        </p>

        <p>
          A <em>virtual package</em> is one which appears in the
          <tt>Provides</tt> control file field of another package.
          The effect is as if the package(s) which provide a
          particular virtual package name had been listed by name
          everywhere the virtual package name appears.
        </p>

        <p>
          If there are both a real and a virtual package of the same
          name then the dependency may be satisfied (or the conflict
          caused) by either the real package or any of the virtual
          packages which provide it.  This is so that, for example,
          supposing we have
          <example compact="compact">
Package: foo
Depends: bar
          </example>
          and someone else releases an enhanced version of the
          <tt>bar</tt> package (for example, a non-US variant), they
          can say:
          <example compact="compact">
Package: bar-plus
Provides: bar
          </example>
          and the <tt>bar-plus</tt> package will now also satisfy the
          dependency for the <tt>foo</tt> package.
        </p>

        <p>
          If a dependency or a conflict has a version number attached
          then only real packages will be considered to see whether
          the relationship is satisfied (or the prohibition violated,
          for a conflict) - it is assumed that a real package which
          provides the virtual package is not of the `right' version.
          So, a <tt>Provides</tt> field may not contain version
          numbers, and the version number of the concrete package
          which provides a particular virtual package will not be
          looked at when considering a dependency on or conflict with
          the virtual package name.
        </p>

        <p>
          It is likely that the ability will be added in a future
          release of <prgn>dpkg</prgn> to specify a version number for
          each virtual package it provides.  This feature is not yet
          present, however, and is expected to be used only
          infrequently.
        </p>

        <p>
          If you want to specify which of a set of real packages
          should be the default to satisfy a particular dependency on
          a virtual package, you should list the real package as an
          alternative before the virtual one.
        </p>
      </sect>


      <sect id="replaces"><heading>Overwriting files and replacing
          packages - <tt>Replaces</tt></heading>

        <p>
          The <tt>Replaces</tt> control file field has two distinct
          purposes, which come into play in different situations.
        </p>

        <sect1><heading>Overwriting files in other packages</heading>

          <p>
            Firstly, as mentioned before, it is usually an error for a
            package to contain files which are on the system in
            another package.
          </p>

          <p>
            However, if the overwriting package declares that it
            <tt>Replaces</tt> the one containing the file being
            overwritten, then <prgn>dpkg</prgn> will replace the file
            from the old package with that from the new.  The file
            will no longer be listed as `owned' by the old package.
          </p>

          <p>
            If a package is completely replaced in this way, so that
            <prgn>dpkg</prgn> does not know of any files it still
            contains, it is considered to have `disappeared'.  It will
            be marked as not wanted on the system (selected for
            removal) and not installed.  Any <tt>conffile</tt>s
            details noted for the package will be ignored, as they
            will have been taken over by the overwriting package.  The
            package's <prgn>postrm</prgn> script will be run with a
            special argument to allow the package to do any final
            cleanup required.  See <ref id="mscriptsinstact">.
          </p>

          <p>
            If an installed package, <tt>foo</tt> say, declares that
            it replaces another, <tt>bar</tt>, and an attempt is made
            to install <tt>bar</tt>, <prgn>dpkg</prgn> will discard
            files in the <tt>bar</tt> package which would overwrite
            those already present in <tt>foo</tt>.  This is so that
            you can install an older version of a package without
            problems.
          </p>

          <p>
            For this usage of <tt>Replaces</tt>, virtual packages (see
            <ref id="virtual">) are not considered when looking at a
            <tt>Replaces</tt> field - the packages declared as being
            replaced must be mentioned by their real names.
          </p>

          <p>
            Furthermore, this usage of <tt>Replaces</tt> only takes
            effect when both packages are at least partially on the
            system at once, so that it can only happen if they do not
            conflict or if the conflict has been overridden.
          </p>

        </sect1>

        <sect1><heading>Replacing whole packages, forcing their
            removal</heading>

          <p>
            Secondly, <tt>Replaces</tt> allows the packaging system to
            resolve which package should be removed when there is a
            conflict - see <ref id="conflicts">.  This usage only
            takes effect when the two packages <em>do</em> conflict,
            so that the two usages of this field do not interfere with
            each other.
          </p>

          <p>
            In this situation, the package declared as being replaced
            can be a virtual package, so for example, all mail
            transport agents (MTAs) would have the following fields in
            their control files:
            <example compact="compact">
Provides: mail-transport-agent
Conflicts: mail-transport-agent
Replaces: mail-transport-agent
            </example>
            ensuring that only one MTA can be installed at any one
            time.
        </sect1>
      </sect>

      <sect><heading>Relationships between source and binary packages -
          <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
          <tt>Build-Conflicts</tt>, <tt>Build-Conflicts-Indep</tt>
        </heading>

        <p>
          A source package may declare a dependency or a conflict on a
          binary package, indicating which packages are required to be
          present on the system in order to build the binary packages
          from the source package.  This is done with the control file
          fields <tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
          <tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>.
          The dependencies and conflicts they define must be satisfied
          (as defined earlier for binary packages) in order to invoke
          the targets in <tt>debian/rules</tt>, as follows:

          <taglist>
            <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
            <item>
              <p>
                The <tt>Build-Depends</tt> and
                <tt>Build-Conflicts</tt> fields must be satisfied when
                any of the following targets is invoked:
                <tt>build</tt>, <tt>binary</tt>, <tt>binary-arch</tt>
                and <tt>binary-indep</tt>.
              </p>
            </item>
            <tag><tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts-Indep</tt></tag>
            <item>
              <p>
                The <tt>Build-Depends-Indep</tt> and
                <tt>Build-Conflicts-Indep</tt> fields must be
                satisfied when any of the following targets is
                invoked: <tt>binary</tt> and <tt>binary-indep</tt>.
              </p>
            </item>
          </taglist>

        </p>

      </sect>
    </chapt>


    <chapt id="conffiles"><heading>Configuration file handling
      </heading>

      <p>
        This chapter has been superseded by <ref id="config files">.
      </p>


    <chapt id="sharedlibs"><heading>Shared libraries</heading>

      <p>
        Packages containing shared libraries must be constructed with
        a little care to make sure that the shared library is always
        available.  This is especially important for packages whose
        shared libraries are vitally important, such as the C library
        (currently <tt>libc6</tt>).
      </p>

      <p>
        Firstly, the package should install the shared libraries under
        their normal names.  For example, the <tt>libgdbmg1</tt>
        package should install <tt>libgdbm.so.1.7.3</tt> as
        <tt>/usr/lib/libgdbm.so.1.7.3</tt>.  The files should not be
        renamed or re-linked by any <prgn>prerm</prgn> or
        <prgn>postrm</prgn> scripts; <prgn>dpkg</prgn> will take care
        of renaming things safely without affecting running programs,
        and attempts to interfere with this are likely to lead to
        problems.
      </p>

      <p>
        Secondly, the package should include the symbolic link that
        <prgn>ldconfig</prgn> would create for the shared libraries.
        For example, the <prgn>libgdbmg1</prgn> package should include
        a symbolic link from <tt>/usr/lib/libgdbm.so.1</tt> to
        <tt>libgdbm.so.1.7.3</tt>.  This is needed so that the dynamic
        linker (for example <prgn>ld.so</prgn> or
        <prgn>ld-linux.so.*</prgn>) can find the library between the
        time that <prgn>dpkg</prgn> installs it and the time that
        <prgn>ldconfig</prgn> is run in the <prgn>postinst</prgn>
        script.
        <footnote>
          <p>
            The package management system requires the library to be
            placed before the symbolic link pointing to it in the
            <tt>.deb</tt> file.  This is so that when
            <prgn>dpkg</prgn> comes to install the symlink
            (overwriting the previous symlink pointing at an older
            version of the library), the new shared library is already
            in place.  In the past, this was achieved by creating the
            library in the temporary packaging directory before
            creating the symlink.  Unfortunately, this was not always
            effective, since the building of the tar file in the
            <tt>.deb</tt> depended on the behavior of the underlying
            file system.  Some file systems (such as reiserfs) reorder
            the files so that the order of creation is forgotten.
            Starting with release <tt>1.7.0</tt>, <prgn>dpkg</prgn>
            will reorder the files itself as necessary when building a
            package.  Thus it is no longer important to concern
            oneself with the order of file creation.
          </p>
        </footnote>
      </p>

      <p>
        Thirdly, the associated development package should contain a
        symlink for the shared library without a version number.  For
        example, the <tt>libgdbmg1-dev</tt> package should include a
        symlink from <tt>/usr/lib/libgdbm.so</tt> to
        <tt>libgdbm.so.1.7.3</tt>.  This symlink is needed by the
        linker (<prgn>ld</prgn>) when compiling packages, as it will
        only look for <tt>libgdbm.so</tt> when compiling dynamically.
      </p>

      <p>
        Any package installing shared libraries in one of the default
        library directories of the dynamic linker (which are currently
        <tt>/usr/lib</tt> and <tt>/lib</tt>) or a directory that is
        listed in <tt>/etc/ld.so.conf</tt>
        <footnote>
          <p>
            These are currently
            <list compact="compact">
              <item><p>/usr/X11R6/lib/Xaw3d</p></item>
              <item><p>/usr/local/lib</p></item>
              <item><p>/usr/lib/libc5-compat</p></item>
              <item><p>/lib/libc5-compat</p></item>
              <item><p>/usr/X11R6/lib</p></item>
            </list>
          </p>
        </footnote>
        must call <prgn>ldconfig</prgn> in its <prgn>postinst</prgn>
        script if the first argument is <tt>configure</tt> and should
        call it in the <prgn>postrm</prgn> script if the first
        argument is <tt>remove</tt>.
      </p>

      <p>
        However, <prgn>postrm</prgn> and <prgn>preinst</prgn> scripts
        <em>must not</em> call <prgn>ldconfig</prgn> in the case where
        the package is being upgraded (see <ref id="unpackphase"> for
        details), as <prgn>ldconfig</prgn> will see the temporary
        names that <prgn>dpkg</prgn> uses for the files while it is
        installing them and will make the shared library links point
        to them, just before <prgn>dpkg</prgn> continues the
        installation and renames the temporary files!
      </p>

      <sect>
        <heading>Handling shared library dependencies - the
          <tt>shlibs</tt> system</heading>

        <p>
          If a package contains a binary or library which links to a
          shared library, we must ensure that when the package is
          installed on the system, all of the libraries needed are
          also installed.  This requirement led to the creation of the
          <tt>shlibs</tt> system, which is very simple in its design:
          any package which <em>provides</em> a shared library also
          provides information on the package dependencies required to
          ensure the presence of this library, and any package which
          <em>uses</em> a shared library uses this information to
          determine the dependencies it requires.  The files which
          contain the mapping from shared libraries to the necessary
          dependency information are called <tt>shlibs</tt> files.
        </p>

        <p>
          Thus, when a package is built which contains any shared
          libraries, it must provide a <tt>shlibs</tt> file for other
          packages to use, and when a package is built which contains
          any shared libraries or compiled binaries, it must run
          <prgn>dpkg-shlibdeps</prgn> on these to determine the
          libraries used and hence the dependencies needed by this
          package.
          <footnote>
            <p>
              In the past, the shared libraries linked to were
              determined by calling <prgn>ldd</prgn>, but now
              <prgn>objdump</prgn> to do this.  The only change this
              makes to package building is that
              <prgn>dpkg-shlibdeps</prgn> must also be run on shared
              libraries, whereas in the past this was unnecessary.
              The rest of this footnote explains the advantage that
              this method gives.
            </p>

            <p>
              We say that a binary <tt>foo</tt> <em>directly</em> uses
              a library <tt>libbar</tt> if it is explicitly linked
              with that library (that is, it uses the flag
              <tt>-lbar</tt> during the linking stage).  Other
              libraries that are needed by <tt>libbar</tt> are linked
              <em>indirectly</em> to <tt>foo</tt>, and the dynamic
              linker will load them automatically when it loads
              <tt>libbar</tt>.  A package should needs to depend on
              the libraries it directly uses, and the dependencies for
              those libraries should automatically pull in the other
              libraries.
            </p>

            <p>
              Unfortunately, the <prgn>ldd</prgn> program shows both
              the directly and indirectly used libraries, meaning that
              the dependencies determined included both direct and
              indirect dependencies.  The use of <prgn>objdump</prgn>
              avoids this problem by determining only the directly
              used libraries.
            </p>

            <p>
              A good example of where this helps is the following.  We
              could update <tt>libimlib</tt> with a new version that
              supports a new graphics format called dgf (but retaining
              the same major version number).  If we used the old
              <prgn>ldd</prgn> method, every package that uses
              <tt>libimlib</tt> would need to be recompiled so it
              would also depend on <tt>libdgf</tt> or it wouldn't run
              due to missing symbols.  However with the new system,
              packages using <tt>libimlib</tt> can rely on
              <tt>libimlib</tt> itself having the dependency on
              <tt>libdgf</tt> and so they would not need rebuilding.
            </p>
          </footnote>
        </p>

        <p>
          In the following sections, we will first describe where the
          various <tt>shlibs</tt> files are to be found, then how to
          use <prgn>dpkg-shlibdeps</prgn>, and finally the
          <tt>shlibs</tt> file format and how to create them if your
          package contains a shared library.
        </p>
      </sect>

      <sect><heading>The <tt>shlibs</tt> files present on the system
        </heading>

        <p>
          There are several places where <tt>shlibs</tt> files are
          found.  The following list gives them in the order in which
          they are read by <prgn>dpkg-shlibdeps</prgn>.  (The first
          one which gives the required information is used.)
        </p>

        <p>
          <list>
            <item>
              <p><tt>debian/shlibs.local</tt></p>
              <p>
                This lists overrides for this package.  Its use is
                described below (see <ref id="shlibslocal">).
              </p>
            </item>

            <item>
              <p><tt>/etc/dpkg/shlibs.override</tt></p>
              <p>
                This lists global overrides.  This list is normally
                empty.  It is maintained by the local system
                administrator.
              </p>
            </item>

            <item>
              <p><tt>DEBIAN/shlibs</tt> files in the `build directory'</p>
              <p>
                When packages are being built, any
                <tt>debian/shlibs</tt> files are copied into the
                control file area of the temporary build directory and
                given the name <tt>shlibs</tt>.  These files give
                details of any shared libraries included in the
                package.
                <footnote>
                  <p>
                    An example may help here.  Let us say that the
                    source package <tt>foo</tt> generates two binary
                    packages, <tt>libfoo2</tt> and
                    <tt>foo-runtime</tt>.  When building the binary
                    packages, the two packages are created in the
                    directories <tt>debian/libfoo2</tt> and
                    <tt>debian/foo-runtime</tt> respectively.
                    (<tt>debian/tmp</tt> could be used instead of one
                    of these.)  Since <tt>libfoo2</tt> provides the
                    <tt>libfoo</tt> shared library, it will require a
                    <tt>shlibs</tt> file, which will be installed in
                    <tt>debian/libfoo2/DEBIAN/shlibs</tt>, eventually
                    to become
                    <tt>/var/lib/dpkg/info/libfoo2.shlibs</tt>.  Then
                    when <prgn>dpkg-shlibdeps</prgn> is run on the
                    executable
                    <tt>debian/foo-runtime/usr/bin/foo-prog</tt>, it
                    will examine the
                    <tt>debian/libfoo2/DEBIAN/shlibs</tt> file to
                    determine whether <tt>foo-prog</tt>'s library
                    dependencies are satisfied by any of the libraries
                    provided by <tt>libfoo2</tt>.  For this reason,
                    <prgn>dpkg-shlibdeps</prgn> must only be run once
                    all of the individual binary packages'
                    <tt>shlibs</tt> files have been installed into the
                    build directory.
                  </p>
                </footnote>
              </p>
            </item>

            <item>
              <p><tt>/var/lib/dpkg/info/*.shlibs</tt></p>
              <p>
                These are the <tt>shlibs</tt> files corresponding to
                all of the packages installed on the system, and are
                maintained by the relevant package maintainers.
              </p>
            </item>

            <item>
              <p><tt>/etc/dpkg/shlibs.default</tt></p>
              <p>
                This file lists any shared libraries whose packages
                have failed to provide correct <tt>shlibs</tt> files.
                It was used when the <tt>shlibs</tt> setup was first
                introduced, but it is now normally empty.  It is
                maintained by the <tt>dpkg</tt> maintainer.
              </p>
            </item>
          </list>
        </p>
      </sect>

      <sect>
        <heading>How to use <prgn>dpkg-shlibdeps</prgn> and the
            <tt>shlibs</tt> files</heading>

        <p>
          Put a call to <prgn>dpkg-shlibdeps</prgn> into your
          <tt>debian/rules</tt> file.  If your package contains only
          compiled binaries and libraries (but no scripts), you can
          use a command such as:
          <example compact="compact">
dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/* \
  debian/tmp/usr/lib/*
          </example>
          Otherwise, you will need to explicitly list the compiled
          binaries and libraries.
          <footnote>
            <p>
              If you are using <tt>debhelper</tt>, the
              <prgn>dh_shlibdeps</prgn> program will do this work for
              you.  It will also correctly handle multi-binary
              packages.
            </p>
          </footnote>
        </p>

        <p>
          This command puts the dependency information into the
          <tt>debian/substvars</tt> file, which is then used by
          <prgn>dpkg-gencontrol</prgn>.  You will need to place a
          <tt>${shlib:Depends}</tt> variable in the <tt>Depends</tt>
          field in the control file for this to work.
        </p>

        <p>
          If <prgn>dpkg-shlibdeps</prgn> doesn't complain, you're
          done.  If it does complain you might need to create your own
          <tt>debian/shlibs.local</tt> file, as explained below (see
          <ref id="shlibslocal">).
        </p>

        <p>
          If you have multiple binary packages, you will need to call
          <prgn>dpkg-shlibdeps</prgn> on each one which contains
          compiled libraries or binaries.  In such a case, you will
          need to use the <tt>-T</tt> option to the <tt>dpkg</tt>
          utilities to specify a different <tt>substvars</tt> file.
          For more details on this and other options, see <manref
          name="dpkg-shlibdeps" section="1">.
        </p>
      </sect>

      <sect id="shlibs"><heading>The <tt>shlibs</tt> File Format
        </heading>

        <p>
          Each <tt>shlibs</tt> file has the same format.  Lines
          beginning with <tt>#</tt> are considered to be commments and
          are ignored.  Each line is of the form:
          <example compact="compact">
<var>library-name</var> <var>soname-version-number</var> <var>dependencies ...</var>
          </example>
        </p>

        <p>
          We will explain this by reference to the example of the
          <tt>zlib1g</tt> package, which (at the time of writing)
          installs the shared library <tt>/usr/lib/libz.so.1.1.3</tt>.
        </p>

        <p>
          <var>library-name</var> is the name of the shared library,
          in this case <tt>libz</tt>.  (This must match the name part
          of the soname, see below.)
        </p>

        <p>
          <var>soname-version-number</var> is the version part of the
          soname of the library.  The soname is the thing that must
          exactly match for the library to be recognized by the
          dynamic linker, and is usually of the form
          <tt><var>name</var>.so.<var>major-version</var></tt>, in our
          example, <tt>libz.so.1</tt>.
          <footnote>
            <p>
              This can be determined using the command
              <example compact="compact">
objdump -p /usr/lib/libz.so.1.1.3 | grep SONAME
              </example>
            </p>
          </footnote>
          The version part is the part which comes after
          <tt>.so.</tt>, so in our case, it is <tt>1</tt>.
        </p>

        <p>
          <var>dependencies</var> has the same syntax as a dependency
          field in a binary package control file.  It should give
          details of which packages are required to satisfy a binary
          built against the version of the library contained in the
          package.  See <ref id="depsyntax"> for details.
        </p>

        <p>
          In our example, if the first version of the <tt>zlib1g</tt>
          package which contained a minor number of at least
          <tt>1.3</tt> was <var>1:1.1.3-1</var>, then the
          <tt>shlibs</tt> entry for this library could say:
          <example compact="compact">
libz 1 zlib1g (>= 1:1.1.3)
          </example>
          The version-specific dependency is to avoid warnings from
          the dynamic linker about using older shared libraries with
          newer binaries.
        </p>
      </sect>

      <sect>
        <heading>Providing a <tt>shlibs</tt> file</heading>

        <p>
          If your package provides a shared library, you should create
          a <tt>shlibs</tt> file following the format described above.
          It is usual to call this file <tt>debian/shlibs</tt> (but if
          you have multiple binary packages, you might want to call it
          <tt>debian/shlibs.<var>package</var></tt> instead).  Then
          let <tt>debian/rules</tt> install it in the control area:
          <example compact="compact">
install -m644 debian/shlibs debian/tmp/DEBIAN
          </example>
          or, in the case of a multi-binary package:
          <example compact="compact">
install -m644 debian/shlibs.<var>package</var> debian/<var>package</var>/DEBIAN/shlibs
          </example>
          An alternative way of doing this is to create the
          <tt>shlibs</tt> file in the control area directly from
          <tt>debian/rules</tt> without using a <tt>debian/shlibs</tt>
          file at all,
          <footnote>
            <p>
              This is what <prgn>dh_makeshlibs</prgn> in the
              <tt>debhelper</tt> suite does.
            </p>
          </footnote>
          since the <tt>debian/shlibs</tt> file itself is ignored by
          <prgn>dpkg-shlibdeps</prgn>.
        </p>

        <p>
          As <prgn>dpkg-shlibdeps</prgn> reads the
          <tt>DEBIAN/shlibs</tt> files in all of the binary packages
          being built from this source package, all of the
          <tt>DEBIAN/shlibs</tt> files should be installed before
          <prgn>dpkg-shlibdeps</prgn> is called on any of the binary
          packages.
        </p>
      </sect>

      <sect id="shlibslocal">
        <heading>Writing the <tt>debian/shlibs.local</tt> file</heading>

        <p>
          This file is intended only as a <em>temporary</em> fix if
          your binaries or libraries depend on a library whose package
          does not yet provide a correct <tt>shlibs</tt> file.
        </p>

        <p>
          We will assume that you are trying to package a binary
          <tt>foo</tt>.  When you try running
          <prgn>dpkg-shlibdeps</prgn> you get the following error
          message (<tt>-O</tt> displays the dependency information on
          <tt>stdout</tt> instead of writing it to
          <tt>debian/substvars</tt>, and the lines have been wrapped
          for ease of reading):
          <example compact="compact">
$ dpkg-shlibdeps -O debian/tmp/usr/bin/foo
dpkg-shlibdeps: warning: unable to find dependency
  information for shared library libbar (soname 1,
  path /usr/lib/libbar.so.1, dependency field Depends)
shlibs:Depends=libc6 (>= 2.2.2-2)
          </example>
          You can then run <prgn>ldd</prgn> on the binary to find the
          full location of the library concerned:
          <example compact="compact">
$ ldd foo
libbar.so.1 => /usr/lib/libbar.so.1 (0x4001e000)
libc.so.6 => /lib/libc.so.6 (0x40032000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
          </example>
          So the <prgn>foo</prgn> binary depends on the
          <prgn>libbar</prgn> shared library, but no package seems to
          provide a <tt>*.shlibs</tt> file handling
          <tt>libbar.so.1</tt> in <tt>/var/lib/dpkg/info/</tt>.  Let's
          determine the package responsible:
          <example compact="compact">
$ dpkg -S /usr/lib/libbar.so.1
bar1: /usr/lib/libbar.so.1
$ dpkg -s bar1 | grep Version
Version: 1.0-1
          </example>
          This tells us that the <tt>bar1</tt> package, version 1.0-1,
          is the one we are using.  Now we can file a bug against the
          <tt>bar1</tt> package and create our own
          <tt>debian/shlibs.local</tt> to locally fix the problem.
          Including the following line into your
          <tt>debian/shlibs.local</tt> file:
          <example compact="compact">
libbar 1 bar1 (>= 1.0-1)
          </example>
          should allow the package build to work.
        </p>

        <p>
          As soon as the maintainer of <tt>bar1</tt> provides a
          correct <tt>shlibs</tt> file, you should remove this line
          from your <tt>debian/shlibs.local</tt> file.  (You should
          probably also then have a versioned <tt>Build-Depends</tt>
          on <tt>bar1</tt> to help ensure that others do not have the
          same problem building your package.)
        </p>
      </sect>
    </chapt>

    <chapt id="opersys"><heading>The Operating System</heading>

      <sect>
        <heading>Filesystem hierarchy</heading>


        <sect1>
          <heading>Filesystem Structure</heading>

          <p>
            The location of all installed files and directories must
            comply with the Filesystem Hierarchy Standard (FHS),
            version 2.1.  This can be found in the
            <tt>debian-policy</tt> package or on <url
            id="http://www.debian.org/doc/packaging-manuals/fhs"
            name="FHS (Debian copy)"> alongside this manual or on <url
            id="http://www.pathname.com/fhs/" name="FHS (upstream)">.
            Specific questions about following the standard may be
            asked on the <tt>debian-devel</tt> mailing list, or
            referred to Daniel Quinlan, the FHS coordinator, at
            <email>quinlan@pathname.com</email>.
          </p>
        </sect1>

        <sect1>
          <heading>Site-specific programs</heading>

          <p>
            As mandated by the FHS, packages must not place any
            files in <tt>/usr/local</tt>, either by putting them in
            the file system archive to be unpacked by <prgn>dpkg</prgn>
            or by manipulating them in their maintainer scripts.
          </p>

          <p>
            However, the package may create empty directories below
            <tt>/usr/local</tt> so that the system administrator knows
            where to place site-specific files.  These directories
            should be removed on package removal if they are
            empty.
          </p>

          <p>
            Note, that this applies only to directories <em>below</em>
            <tt>/usr/local</tt>, not <em>in</em> <tt>/usr/local</tt>.
            Packages must not create sub-directories in the directory
            <tt>/usr/local</tt> itself, except those listed in FHS,
            section 4.5.  However, you may create directories below
            them as you wish. You must not remove any of the
            directories listed in 4.5, even if you created them.
          </p>

          <p>
            Since <tt>/usr/local</tt> can be mounted read-only from a
            remote server, these directories must be created and
            removed by the <prgn>postinst</prgn> and <prgn>prerm</prgn>
            maintainer scripts and not be included in the
            <tt>.deb</tt> archive.  These scripts must not fail if
            either of these operations fail.
            <footnote>
              <p>
                In the future, it may be possible to tell
                <prgn>dpkg</prgn> not to unpack files matching certain
                patterns, so that the directories can be included in
                the <tt>.deb</tt> packages and system administrators
                who do not wish these directories in
                <tt>/usr/local</tt> do not need to have them.)
              </p>
            </footnote>
          </p>

          <p>
            For example, the <tt>emacsen-common</tt> package could
            contain something like
            <example compact="compact">
if [ ! -e /usr/local/share/emacs ]
then
  if mkdir /usr/local/share/emacs 2>/dev/null
  then
    chown root:staff /usr/local/share/emacs
    chmod 2775 /usr/local/share/emacs
  fi
fi
            </example>
            in its <prgn>postinst</prgn> script, and
            <example compact="compact">
rmdir /usr/local/share/emacs/site-lisp 2>/dev/null || true
rmdir /usr/local/share/emacs 2>/dev/null || true
            </example>
            in the <prgn>prerm</prgn> script.  (Note that this form is
            used to ensure that if the script is interrupted, the
            directory <tt>/usr/local/share/emacs</tt> will still be
            removed.)
          </p>

          <p>
            If you do create a directory in <tt>/usr/local</tt> for
            local additions to a package, you should ensure that
            settings in <tt>/usr/local</tt> take precedence over the
            equivalents in <tt>/usr</tt>.
          </p>

          <p>
            However, because <tt>/usr/local</tt> and its contents are
            for exclusive use of the local administrator, a package
            must not rely on the presence or absence of files or
            directories in <tt>/usr/local</tt> for normal operation.
          </p>

          <p>
            The <tt>/usr/local</tt> directory itself and all the
            subdirectories created by the package should (by default) have
            permissions 2775 (group-writable and set-group-id) and be
            owned by <tt>root.staff</tt>.
          </p>
        </sect1>

        <sect1>
          <heading>The system-wide mail directory</heading>
          <p>
            The system-wide mail directory is <tt>/var/mail</tt>. This
            directory is part of the base system and should not owned
            by any particular mail agents.  The use of the old
            location <tt>/var/spool/mail</tt> is deprecated, even
            though the spool may still be physically located there.
            To maintain partial upgrade compatibility for systems
            which have <tt>/var/spool/mail</tt> as their physical mail
            spool, packages using <tt>/var/mail</tt> must depend on
            either <package>libc6</package> (&gt;= 2.1.3-13), or on
            <package>base-files</package> (&gt;= 2.2.0), or on later
            versions of either one of these packages.
          </p>
        </sect1>
      </sect>

      <sect>
        <heading>Users and groups</heading>

        <sect1>
          <heading>Introduction</heading>
          <p>
            The Debian system can be configured to use either plain or
            shadow passwords.
          </p>

          <p>
            Some user ids (UIDs) and group ids (GIDs) are reserved
            globally for use by certain packages.  Because some
            packages need to include files which are owned by these
            users or groups, or need the ids compiled into binaries,
            these ids must be used on any Debian system only for the
            purpose for which they are allocated. This is a serious
            restriction, and we should avoid getting in the way of
            local administration policies. In particular, many sites
            allocate users and/or local system groups starting at 100.
          </p>

          <p>
            Apart from this we should have dynamically allocated ids,
            which should by default be arranged in some sensible
            order, but the behavior should be configurable.
          </p>

          <p>
            Packages other than <tt>base-passwd</tt> must not modify
            <tt>/etc/passwd</tt>, <tt>/etc/shadow</tt>,
            <tt>/etc/group</tt> or <tt>/etc/gshadow</tt>.
          </p>
        </sect1>

        <sect1>
          <heading>UID and GID classes</heading>
          <p>
            The UID and GID numbers are divided into classes as
            follows:
            <taglist>
              <tag>0-99:</tag>
              <item>
                <p>
                  Globally allocated by the Debian project, the same
                  on every Debian system.  These ids will appear in
                  the <tt>passwd</tt> and <tt>group</tt> files of all
                  Debian systems, new ids in this range being added
                  automatically as the <tt>base-passwd</tt> package is
                  updated.
                </p>

                <p>
                  Packages which need a single statically allocated
                  uid or gid should use one of these; their
                  maintainers should ask the <tt>base-passwd</tt>
                  maintainer for ids.
                </p>
              </item>

              <tag>100-999:</tag>
              <item>
                <p>
                  Dynamically allocated system users and groups.
                  Packages which need a user or group, but can have
                  this user or group allocated dynamically and
                  differently on each system, should use <tt>adduser
                  --system</tt> to create the group and/or user.
                  <prgn>adduser</prgn> will check for the existence of
                  the user or group, and if necessary choose an unused
                  id based on the ranges specified in
                  <tt>adduser.conf</tt>.
                </p>
              </item>

              <tag>1000-29999:</tag>
              <item>
                <p>
                  Dynamically allocated user accounts.  By default
                  <prgn>adduser</prgn> will choose UIDs and GIDs for
                  user accounts in this range, though
                  <tt>adduser.conf</tt> may be used to modify this
                  behavior.
                </p>
              </item>

              <tag>30000-59999:</tag>
              <item>
                <p>Reserved.</p>
              </item>

              <tag>60000-64999:</tag>
              <item>
                <p>
                  Globally allocated by the Debian project, but only
                  created on demand. The ids are allocated centrally
                  and statically, but the actual accounts are only
                  created on users' systems on demand.
                </p>

                <p>
                  These ids are for packages which are obscure or
                  which require many statically-allocated ids.  These
                  packages should check for and create the accounts in
                  <tt>/etc/passwd</tt> or <tt>/etc/group</tt> (using
                  <prgn>adduser</prgn> if it has this facility) if
                  necessary.  Packages which are likely to require
                  further allocations should have a `hole' left after
                  them in the allocation, to give them room to
                  grow.
                </p>
              </item>

              <tag>65000-65533:</tag>
              <item>
                <p>Reserved.</p>
              </item>

              <tag>65534:</tag>
              <item>
                <p>
                  User <tt>nobody</tt>. The corresponding gid refers
                  to the group <tt>nogroup</tt>.
                </p>
              </item>

              <tag>65535:</tag>
              <item>
                <p>
                  <tt>(uid_t)(-1) == (gid_t)(-1)</tt> <em>must
                  not</em> be used, because it is the error return
                  sentinel value.
                </p>
              </item>
            </taglist>
          </p>
        </sect1>
      </sect>

      <sect id="sysvinit">
        <heading>System run levels and <tt>init.d</tt> scripts</heading>

        <sect1 id="/etc/init.d">
          <heading>Introduction</heading>

          <p>
            The <tt>/etc/init.d</tt> directory contains the scripts
            executed by <prgn>init</prgn> at boot time and when the
            init state (or `runlevel') is changed (see <manref
            name="init" section="8">).
          </p>

          <p>
            There are at least two different, yet functionally
            equivalent, ways of handling these scripts.  For the sake
            of simplicity, this document describes only the symbolic
            link method. However, it must not be assumed by maintainer
            scripts that this method is being used, and any automated
            manipulation of the various runlevel behaviours by
            maintainer scripts must be performed using
            <prgn>update-rc.d</prgn> as described below and not by
            manually installing or removing symlinks.  For information
            on the implementation details of the other method,
            implemented in the <tt>file-rc</tt> package, please refer
            to the documentation of that package.
          </p>

          <p>
            These scripts are referenced by symbolic links in the
            <tt>/etc/rc<var>n</var>.d</tt> directories.  When changing
            runlevels, <prgn>init</prgn> looks in the directory
            <tt>/etc/rc<var>n</var>.d</tt> for the scripts it should
            execute, where <tt><var>n</var></tt> is the runlevel that
            is being changed to, or <tt>S</tt> for the boot-up
            scripts.
          </p>

          <p>
            The names of the links all have the form
            <tt>S<var>mm</var><var>script</var></tt> or
            <tt>K<var>mm</var><var>script</var></tt> where
            <var>mm</var> is a two-digit number and <var>script</var>
            is the name of the script (this should be the same as the
            name of the actual script in <tt>/etc/init.d</tt>).
          </p>

          <p>
            When <prgn>init</prgn> changes runlevel first the targets
            of the links whose names start with a <tt>K</tt> are
            executed, each with the single argument <tt>stop</tt>,
            followed by the scripts prefixed with an <tt>S</tt>, each
            with the single argument <tt>start</tt>.  (The links are
            those in the <tt>/etc/rc<var>n</var>.d</tt> directory
            corresponding to the new runlevel.)  The <tt>K</tt> links
            are responsible for killing services and the <tt>S</tt>
            link for starting services upon entering the runlevel.
          </p>

          <p>
            For example, if we are changing from runlevel 2 to
            runlevel 3, init will first execute all of the <tt>K</tt>
            prefixed scripts it finds in <tt>/etc/rc3.d</tt>, and then
            all of the <tt>S</tt> prefixed scripts in that directory.
            The links starting with <tt>K</tt> will cause the
            referred-to file to be executed with an argument of
            <tt>stop</tt>, and the <tt>S</tt> links with an argument
            of <tt>start</tt>.
          </p>

          <p>
            The two-digit number <var>mm</var> is used to determine
            the order in which to run the scripts: low-numbered links
            have their scripts run first.  For example, the
            <tt>K20</tt> scripts will be executed before the
            <tt>K30</tt> scripts.  This is used when a certain service
            must be started before another.  For example, the name
            server <prgn>bind</prgn> might need to be started before
            the news server <prgn>inn</prgn> so that <prgn>inn</prgn>
            can set up its access lists.  In this case, the script
            that starts <prgn>bind</prgn> would have a lower number
            than the script that starts <prgn>inn</prgn> so that it
            runs first:
            <example compact="compact">
/etc/rc2.d/S17bind
/etc/rc2.d/S70inn
            </example>
          </p>

          <p>
            The two runlevels 0 (halt) and 6 (reboot) are slightly
            different.  In these runlevels, the links with an
            <tt>S</tt> prefix are still called after those with a
            <tt>K</tt> prefix, but they too are called with the single
            argument <tt>stop</tt>.
          </p>

          <p>
            Also, if the script name ends <tt>.sh</tt>, the script
            will be sourced in runlevel <tt>S</tt> rather that being
            run in a forked subprocess, but will be explicitly run by
            <prgn>sh</prgn> in all other runlevels.
          </p>
        </sect1>

        <sect1>
          <heading>Writing the scripts</heading>

          <p>
            Packages that include daemons for system services should
            place scripts in <tt>/etc/init.d</tt> to start or stop
            services at boot time or during a change of runlevel.
            These scripts should be named
            <tt>/etc/init.d/<var>package</var></tt>, and they should
            accept one argument, saying what to do:

            <taglist>
              <tag><tt>start</tt></tag>
              <item><p>start the service,</p></item>

              <tag><tt>stop</tt></tag>
              <item><p>stop the service,</p></item>

              <tag><tt>restart</tt></tag>
              <item><p>stop and restart the service,</p></item>

              <tag><tt>reload</tt></tag>
              <item><p>cause the configuration of the service to be
                  reloaded without actually stopping and restarting
                  the service,</p></item>

              <tag><tt>force-reload</tt></tag> <item><p>cause the
                  configuration to be reloaded if the service supports
                  this, otherwise restart the service.</p></item>
            </taglist>

            The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, and
            <tt>force-reload</tt> options should be supported by all
            scripts in <tt>/etc/init.d</tt>, the <tt>reload</tt>
            option is optional.</p>

          <p>
            The <tt>init.d</tt> scripts should ensure that they will
            behave sensibly if invoked with <tt>start</tt> when the
            service is already running, or with <tt>stop</tt> when it
            isn't, and that they don't kill unfortunately-named user
            processes.  The best way to achieve this is usually to use
            <prgn>start-stop-daemon</prgn>.</p>

          <p>
            If a service reloads its configuration automatically (as
            in the case of <prgn>cron</prgn>, for example), the
            <tt>reload</tt> option of the <tt>init.d</tt> script
            should behave as if the configuration has been reloaded
            successfully.</p>

          <p>
            The <tt>/etc/init.d</tt> scripts should be treated as
            configuration files, either by marking them as
            <tt>conffile</tt>s or managing them correctly in the
            maintainer scripts (see <ref id="config files">).  This is
            important since we want to give the local system
            administrator the chance to adapt the scripts to the local
            system, e.g., to disable a service without de-installing
            the package, or to specify some special command line
            options when starting a service, while making sure her
            changes aren't lost during the next package upgrade.
          </p>

          <p>
            These scripts should not fail obscurely when the
            configuration files remain but the package has been
            removed, as configuration files remain on the system after
            the package has been removed.  Only when <prgn>dpkg</prgn>
            is executed with the <tt>--purge</tt> option will
            configuration files be removed.  In particular, as the
            <tt>/etc/init.d/<var>package</var></tt> script itself is
            usually a <tt>conffile</tt>, it will remain on the system
            if the package is removed but not purged.  Therefore, you
            should include a <tt>test</tt> statement at the top of the
            script, like this:
            <example compact="compact">
test -f <var>program-executed-later-in-script</var> || exit 0
            </example>
          </p>

          <p>
            Often there are some variables in the <tt>init.d</tt>
            scripts whose values control the bahaviour of the scripts,
            and which a system administrator is likely to want to
            change.  As the scripts themselves are frequently
            <tt>conffile</tt>s, modifying them requires that the
            administrator merge in their changes each time the package
            is upgraded and the <tt>conffile changes</tt>.  To ease
            the burden on the system administrator, such configurable
            values should not be placed directly in the script.
            Instead, they should be placed in a file in
            <tt>/etc/default</tt>, which typically will have thesame
            base name as the <tt>init.d</tt> script.  This extra file
            should be sourced by the script when the script runs.  It
            must contain only variable settings and comments in POSIX
            <prgn>sh</prgn> format.  It should not be a
            <tt>conffile</tt>, but a configuration file maintained by
            the package maintainer scripts.  See <ref id="config files">
            for more details.
          </p>

          <p>
            To ensure that vital configurable values are always
            available, the <tt>init.d</tt> script should set default
            values for each of the shell variables it uses, either
            before sourcing the <tt>/etc/default/</tt> file or
            afterwards using something like the <tt>:
            ${VAR:=default}</tt> syntax.  Also, the <tt>init.d</tt>
            script must behave sensibly and not fail if the
            <tt>/etc/default</tt> file is deleted.
          </p>
        </sect1>

        <sect1>
          <heading>Managing the links</heading>

          <p>
            The program <prgn>update-rc.d</prgn> is provided for
            package maintainers to arrange for the proper creation and
            removal of <tt>/etc/rc<var>n</var>.d</tt> symbolic links,
            or their functional equivalent if another method is being
            used.  This may be used by maintainers in their packages'
            <prgn>postinst</prgn> and <prgn>postrm</prgn> scripts.</p>

          <p>
            You must not include any <tt>/etc/rc<var>n</var>.d</tt>
            symbolic links in the actual archive or manually create or
            remove the symbolic links in maintainer scripts; you must
            use the <prgn>update-rc.d</prgn> program instead.  (The
            former will fail if an alternative method of maintaining
            runlevel information is being used.)  You must not include
            the <tt>/etc/rc<var>n</var>.d</tt> directories themselves
            in the archive either.  (Only the <tt>sysvinit</tt>
            package may do so.)
          </p>

          <p>
            By default <prgn>update-rc.d</prgn> will start services in
            each of the multi-user state runlevels (2, 3, 4, and 5)
            and stop them in the halt runlevel (0), the single-user
            runlevel (1) and the reboot runlevel (6).  The system
            administrator will have the opportunity to customize
            runlevels by simply adding, moving, or removing the
            symbolic links in <tt>/etc/rc<var>n</var>.d</tt> if
            symbolic links are being used, or by modifying
            <tt>/etc/runlevel.conf</tt> if the <tt>file-rc</tt> method
            is being used.
          </p>

          <p>
            To get the default behavior for your package, put in your
            <prgn>postinst</prgn> script
            <example compact="compact">
update-rc.d <var>package</var> defaults &gt;/dev/null
            </example>
            and in your <prgn>postrm</prgn>
            <example compact="compact">
if [ "$1" = purge ]; then
  update-rc.d <var>package</var> remove &gt;/dev/null
fi
            </example></p>

          <p>
            This will use a default sequence number of 20.  If it does
            not matter when or in which order the <tt>init.d</tt>
            script is run, use this default.  If it does, then you
            should talk to the maintainer of the <prgn>sysvinit</prgn>
            package or post to <tt>debian-devel</tt>, and they will
            help you choose a number.
          </p>

          <p>
            For more information about using <tt>update-rc.d</tt>,
            please consult its manpage <manref name="update-rc.d"
              section="8">.
          </p>
        </sect1>


        <sect1>
          <heading>Boot-time initialization</heading>

          <p>
            There used to be another directory, <tt>/etc/rc.boot</tt>,
            which contained scripts which were run once per machine
            boot. This has been deprecated in favour of links from
            <tt>/etc/rcS.d</tt> to files in <tt>/etc/init.d</tt> as
            described in <ref id="/etc/init.d">.  Packages must not
            place files in <tt>/etc/rc.boot</tt>.</p>

        <sect1>
          <heading>Example</heading>

          <p>
            The <prgn>bind</prgn> DNS (nameserver) package wants to
            make sure that the nameserver is running in multiuser
            runlevels, and is properly shut down with the system.  It
            puts a script in <tt>/etc/init.d</tt>, naming the script
            appropriately <tt>bind</tt>.  As you can see, the script
            interprets the argument <tt>reload</tt> to send the
            nameserver a <tt>HUP</tt> signal (causing it to reload its
            configuration); this way the system administrator can say
            <tt>/etc/init.d/bind reload</tt> to reload the name
            server.  The script has one configurable value, which can
            be used to pass parameters to the named program at
            startup; this value is read from
            <tt>/etc/default/bind</tt> (see below).
          </p>

          <p>
            <example compact="compact">
#!/bin/sh
#
# Original version by Robert Leslie
# &lt;rob@mars.org&gt;, edited by iwj and cs

test -x /usr/sbin/named || exit 0

# Source defaults file.
PARAMS=''
if [ -f /etc/default/bind ]; then
  . /etc/default/bind
fi


case "$1" in
start)
  echo -n "Starting domain name service: named"
  start-stop-daemon --start --quiet --exec /usr/sbin/named \
                    -- $PARAMS
  echo "."
  ;;
stop)
  echo -n "Stopping domain name service: named"
  start-stop-daemon --stop --quiet  \
    --pidfile /var/run/named.pid --exec /usr/sbin/named
  echo "."
  ;;
restart)
  echo -n "Restarting domain name service: named"
  start-stop-daemon --stop --quiet  \
    --pidfile /var/run/named.pid --exec /usr/sbin/named
  start-stop-daemon --start --verbose --exec /usr/sbin/named \
                    -- $PARAMS
  echo "."
  ;;
force-reload|reload)
  echo -n "Reloading configuration of domain name service: named"
  start-stop-daemon --stop --signal 1 --quiet  \
    --pidfile /var/run/named.pid --exec /usr/sbin/named
  echo "."
  ;;
*)
  echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2
  exit 1
  ;;
esac

exit 0
            </example>
          </p>

          <p>
            Complementing the above init script is a configuration
            file <tt>/etc/default/bind</tt>, which contains
            configurable parameters used by the script.  This would be
            created by the <prgn>postinst</prgn> script if it was not
            already present, and removed on purge by the
            <prgn>postrm</prgn> script.
            <example compact="compact">
# Specified parameters to pass to named. See named(8).
# You may uncomment the following line, and edit to taste.
#PARAMS="-u nobody"
            </example>
          </p>

          <p>
            Another example on which you can base your
            <tt>/etc/init.d</tt> scripts is found in
            <tt>/etc/init.d/skeleton</tt>.
          </p>

          <p>
            If this package is happy with the default setup from
            <prgn>update-rc.d</prgn>, namely an ordering number of 20
            and having named running in all runlevels, it can say in
            its <prgn>postinst</prgn>:
            <example compact="compact">
update-rc.d bind defaults >/dev/null
            </example>
            And in its <prgn>postrm</prgn>, to remove the links when the
            package is purged:
            <example compact="compact">
if [ "$1" = purge ]; then
  update-rc.d bind remove >/dev/null
fi
            </example>
          </p>
        </sect1>
      </sect>

      <sect>
        <heading>Console messages from <tt>init.d</tt> scripts</heading>

        <p>
          This section describes the formats to be used for messages
          written to standard output by the <tt>/etc/init.d</tt>
          scripts.  The intent is to improve the consistency of
          Debian's startup and shutdown look and feel.  For this
          reason, please look very carefully at the details.  We want
          the messages to have the same format in terms of wording,
          spaces, punctuation and case of letters.
        </p>

        <p>
          Here is a list of overall rules that you should use when you
          create output messages.  They can be useful if you have a
          non-standard message that is not covered specifically in the
          sections below.
        </p>

        <p>
          <list>
            <item>
              <p>
                Every message should fit in one line (fewer than 80
                characters), start with a capital letter and end with
                a period (<tt>.</tt>) and line feed (<tt>"\n"</tt>).
              </p>
            </item>

            <item>
              <p>
                If you want to express that the computer is working on
                something (that is, performing a specific task, not
                starting or stopping a program), we use an "ellipsis"
                (three dots: <tt>...</tt>).  Note that we don't insert
                spaces before or after the dots.  If the task has been
                completed we write <tt>done.</tt> and a line feed.
              </p>
            </item>

            <item>
              <p>
                Design your messages as if the computer is telling you
                what he is doing (let him be polite :-), but don't
                mention "him" directly.  For example, if you think of
                saying
                <example compact="compact">
I'm starting network daemons: nfsd mountd.
                </example>
                just say
                <example compact="compact">
Starting network daemons: nfsd mountd.
                </example>
              </p>
            </item>
          </list>
        </p>

        <p>
          There are standard message formats for the following
          situations.  They should be used by the <tt>init.d</tt>
          scripts.
        </p>

        <p>
          <list>
            <item>
              <p>When daemons are started</p>

              <p>
                If your script starts one or more daemons, the output
                should look like this (a single line, no leading
                spaces):
                <example compact="compact">
Starting <var>description</var>: <var>daemon-1</var> ... <var>daemon-n</var>.
                </example>
                The <var>description</var> should describe the
                subsystem the daemon or set of daemons are part of,
                while <var>daemon-1</var> up to <var>daemon-n</var>
                denote each daemon's name (typically the file name of
                the program).
              </p>

              <p>
                For example, the output of <tt>/etc/init.d/lpd</tt>
                would look like:
                <example compact="compact">
Starting printer spooler: lpd.
                </example>
              </p>

              <p>
                This can be achieved by saying
                <example compact="compact">
echo -n "Starting printer spooler: lpd"
start-stop-daemon --start --quiet --exec /usr/sbin/lpd
echo "."
                </example>
                in the script. If you have more than one daemon to
                start, you should do the following:
                <example compact="compact">
echo -n "Starting remote file system services:"
echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
echo -n " mountd"; start-stop-daemon --start --quiet mountd
echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
echo "."
                </example>
                This makes it possible for the user to see what takes
                so long and when the final daemon has been started.
                You should be careful where to put spaces: in the
                example above the system administrator can easily
                comment out a line if he don't wants to start a
                specific daemon, while the displayed message still
                looks good.
              </p>
            </item>

            <item>
              <p>When a system parameter is being set</p>

              <p>
                If you have to set up different system parameters
                during the system boot, you should use this format:
                <example compact="compact">
Setting <var>parameter</var> to `<var>value</var>'.
                </example>
              </p>

              <p>
                You can use a statement such as the following to get
                the quotes right:
                <example compact="compact">
echo "Setting DNS domainname to \`$domainname'."
                </example>
              </p>

              <p>
                Note that the left quotation mark (<tt>`</tt>) is
                different from the right one (<tt>'</tt>).
              </p>
            </item>

            <item>
              <p>When a daemon is stopped or restarted</p>

              <p>
                When you stop or restart a daemon, you should issue a
                message identical to the startup message, except that
                <tt>Starting</tt> is replaced with <tt>Stopping</tt>
                or <tt>Restarting</tt> respectively.
              </p>

              <p>
                For example, stopping the printer daemon will like
                like this:
                <example compact="compact">
Stopping printer spooler: lpd.
                </example>
              </p>
            </item>

            <item>
              <p>When something is executed</p>

              <p>
                There are several examples where you have to run a
                program at system startup or shutdown to perform a
                specific task, for example, setting the system's clock
                using <prgn>netdate</prgn> or killing all processes
                when the system shuts down.  Your message should look
                like this:
                <example compact="compact">
Doing something very useful...done.
                </example>
                You should print the <tt>done.</tt> immediately after
                the job has been completed, so that the user is
                informed why she has to wait.  You can get this
                behavior by saying
                <example compact="compact">
echo -n "Doing something very useful..."
do_something
echo "done."
                </example>
                in your script.
              </p>
            </item>

            <item>
              <p>When the configuration is reloaded</p>

              <p>
                When a daemon is forced to reload its configuration
                files you should use the following format:
                <example compact="compact">
Reloading <var>description</var> configuration...done.
                </example>
                where <var>description</var> is the same as in the
                daemon starting message.
              </p>
            </item>
          </list>
        </p>
      </sect>

      <sect>
        <heading>Cron jobs</heading>

        <p>
          Packages must not modify the configuration file
          <tt>/etc/crontab</tt>, and they must not modify the files in
          <tt>/var/spool/cron/crontabs</tt>.</p>

        <p>
          If a package wants to install a job that has to be executed
          via cron, it should place a file with the name of the
          package in one or more of the following directories:
          <example compact="compact">
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
          </example>
          As these directory names imply, the files within them are
          executed on a daily, weekly, or monthly basis,
          respectively. The exact times are listed in
          <tt>/etc/crontab</tt>.</p>

        <p>
          All files installed in any of these directories must be
          scripts (e.g., shell scripts or Perl scripts) so that they
          can easily be modified by the local system administrator.
          In addition, they should be treated as configuration
          files.
        </p>

        <p>
          If a certain job has to be executed more frequently than
          daily, the package should install a file
          <tt>/etc/cron.d/<var>package</var></tt>. This file uses the
          same syntax as <tt>/etc/crontab</tt> and is processed by
          <prgn>cron</prgn> automatically. The file must also be
          treated as a configuration file. (Note that entries in the
          <tt>/etc/cron.d</tt> directory are not handled by
          <prgn>anacron</prgn>. Thus, you should only use this
          directory for jobs which may be skipped if the system is not
          running.)</p>

        <p>
          The scripts or crontab entries in these directories should
          check if all necessary programs are installed before they
          try to execute them. Otherwise, problems will arise when a
          package was removed but not purged since configuration files
          are kept on the system in this situation.</p>
      </sect>

      <sect>
        <heading>Menus</heading>

        <p>
          Menu entries should follow the current menu policy found in
          the <tt>menu-policy</tt> files in the <tt>debian-policy</tt>
          package.  It may also be found on the Debian FTP site
          <ftpsite>ftp.debian.org</ftpsite> as the file
          <ftppath>/debian/doc/package-developer/menu-policy.txt.gz</ftppath>,
          or in the equivalent location on your local mirror.
        </p>

        <p>
          The Debian <tt>menu</tt> package provides a standard
          interface between packages providing applications and
          documents, and <em>menu programs</em> (either X window
          managers or text-based menu programs such as
          <prgn>pdmenu</prgn>).
        </p>

        <p>
          All packages that provide applications that need not be
          passed any special command line arguments for normal
          operation should register a menu entry for those
          applications, so that users of the <tt>menu</tt> package
          will automatically get menu entries in their window
          managers, as well in shells like <tt>pdmenu</tt>.</p>

        <p>
          Please also refer to the <em>Debian Menu System</em>
          documentation that comes with the <tt>menu</tt> package for
          information about how to register your applications and web
          documents.
        </p>
      </sect>

      <sect>
        <heading>Multimedia handlers</heading>

        <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 found in
          the <tt>mime-policy</tt> files in the <tt>debian-policy</tt>
          package.  It may also be found on the Debian FTP site
          <ftpsite>ftp.debian.org</ftpsite> as the file
          <ftppath>/debian/doc/package-developer/mime-policy.txt.gz</ftppath>,
          or in the equivalent location on your local mirror.
        </p>

        <p>
          MIME (Multipurpose Internet Mail Extensions, RFCs 2045-2049)
          is a mechanism for encoding files and data streams and
          providing meta-information about them, in particular their
          type (e.g.  audio or video) and format (e.g. PNG, HTML,
          MP3).
        </p>

        <p>
          Registration of MIME type handlers allows programs like mail
          user agents and web browsers to to invoke these handlers to
          view, edit or display MIME types they don't support
          directly.
        </p>
      </sect>

      <sect>
        <heading>Keyboard configuration</heading>

        <p>
          To achieve a consistent keyboard configuration so that all
          applications interpret a keyboard event the same way, all
          programs in the Debian distribution must be configured to
          comply with the following guidelines.
        </p>

        <p>
          The following keys must have the specified interpretations:

          <taglist>
            <tag><tt>&lt;--</tt></tag>
            <item><p>delete the character to the left of the cursor</p></item>

            <tag><tt>Delete</tt></tag>
            <item><p>delete the character to the right of the cursor</p></item>

            <tag><tt>Control+H</tt></tag>
            <item><p>emacs: the help prefix</p></item>
          </taglist>

          The interpretation of any keyboard events should be
          independent of the terminal that is used, be it a virtual
          console, an X terminal emulator, an rlogin/telnet session,
          etc.
        </p>

        <p>
          The following list explains how the different programs
          should be set up to achieve this:
        </p>

        <p>
          <list>
            <item><p><tt>&lt;--</tt> generates <tt>KB_Backspace</tt>
                in X.</p></item>

            <item><p><tt>Delete</tt> generates <tt>KB_Delete</tt> in
                X.</p></item>

            <item>
              <p>
                X translations are set up to make
                <tt>KB_Backspace</tt> generate ASCII DEL, and to make
                <tt>KB_Delete</tt> generate <tt>ESC [ 3 ~</tt> (this
                is the vt220 escape code for the `delete character'
                key).  This must be done by loading the X resources
                using <prgn>xrdb</prgn> on all local X displays, not
                using the application defaults, so that the
                translation resources used correspond to the
                <prgn>xmodmap</prgn> settings.</p></item>

            <item>
              <p>
                The Linux console is configured to make
                <tt>&lt;--</tt> generate DEL, and <tt>Delete</tt>
                generate <tt>ESC [ 3 ~</tt>.</p></item>

            <item>
              <p>
                X applications are configured so that <tt>&lt;</tt>
                deletes left, and <tt>Delete</tt> deletes right.  Motif
                applications already work like this.</p></item>

            <item><p>Terminals should have <tt>stty erase ^?</tt> .</p></item>

            <item>
              <p>
                The <tt>xterm</tt> terminfo entry should have <tt>ESC
                [ 3 ~</tt> for <tt>kdch1</tt>, just as for
                <tt>TERM=linux</tt> and <tt>TERM=vt220</tt>.</p></item>

            <item>
              <p>
                Emacs is programmed to map <tt>KB_Backspace</tt> or
                the <tt>stty erase</tt> character to
                <tt>delete-backward-char</tt>, and <tt>KB_Delete</tt>
                or <tt>kdch1</tt> to <tt>delete-forward-char</tt>, and
                <tt>^H</tt> to <tt>help</tt> as always.</p></item>

            <item>
              <p>
                Other applications use the <tt>stty erase</tt>
                character and <tt>kdch1</tt> for the two delete keys,
                with ASCII DEL being `delete previous character' and
                <tt>kdch1</tt> being `delete character under
                cursor'.</p></item>

          </list>
        </p>

        <p>
          This will solve the problem except for the following
          cases:
        </p>

        <p>
          <list>
            <item>
              <p>
                Some terminals have a <tt>&lt;--</tt> key that cannot
                be made to produce anything except <tt>^H</tt>.  On
                these terminals Emacs help will be unavailable on
                <tt>^H</tt> (assuming that the <tt>stty erase</tt>
                character takes precedence in Emacs, and has been set
                correctly).  <tt>M-x help</tt> or <tt>F1</tt> (if
                available) can be used instead.</p></item>

            <item>
              <p>
                Some operating systems use <tt>^H</tt> for <tt>stty
                erase</tt>.  However, modern telnet versions and all
                rlogin versions propagate <tt>stty</tt> settings, and
                almost all UNIX versions honour <tt>stty erase</tt>.
                Where the <tt>stty</tt> settings are not propagated
                correctly, things can be made to work by using
                <tt>stty</tt> manually.</p></item>

            <item>
              <p>
                Some systems (including previous Debian versions) use
                <prgn>xmodmap</prgn> to arrange for both
                <tt>&lt;--</tt> and <tt>Delete</tt> to generate
                <tt>KB_Delete</tt>.  We can change the behavior of
                their X clients using the same X resources that we use
                to do it for our own clients, or configure our clients
                using their resources when things are the other way
                around.  On displays configured like this
                <tt>Delete</tt> will not work, but <tt>&lt;--</tt>
                will.</p></item>

            <item>
              <p>
                Some operating systems have different <tt>kdch1</tt>
                settings in their <tt>terminfo</tt> database for
                <tt>xterm</tt> and others.  On these systems the
                <tt>Delete</tt> key will not work correctly when you
                log in from a system conforming to our policy, but
                <tt>&lt;--</tt> will.</p></item>
          </list>
        </p>
      </sect>

      <sect>
        <heading>Environment variables</heading>

        <p>
          A program must not depend on environment variables to get
          reasonable defaults.  (That's because these environment
          variables would have to be set in a system-wide
          configuration file like <tt>/etc/profile</tt>, which is not
          supported by all shells.)</p>

        <p>
          If a program usually depends on environment variables for its
          configuration, the program should be changed to fall back to
          a reasonable default configuration if these environment
          variables are not present. If this cannot be done easily
          (e.g., if the source code of a non-free program is not
          available), the program must be replaced by a small
          `wrapper' shell script which sets the environment variables
          if they are not already defined, and calls the original program.</p>

        <p>
          Here is an example of a wrapper script for this purpose:

          <example compact="compact">
#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"
          </example>
        </p>

        <p>
          Furthermore, as <tt>/etc/profile</tt> is a configuration
          file of the <prgn>base-files</prgn> package, other packages must not
          put any environment variables or other commands into that
          file.</p>
      </sect>
    </chapt>

    <chapt id="files">
      <heading>Files</heading>

      <sect>
        <heading>Binaries</heading>

        <p>
          Two different packages must not install programs with
          different functionality but with the same filenames.  (The
          case of two programs having the same functionality but
          different implementations is handled via `alternatives' or
          the `Conflicts' mechanism.  See <ref id="maintscripts"> and
          <ref id="conflicts"> respectively.)  If this case happens,
          one of the programs must be renamed.  The maintainers should
          report this to the <tt>debian-devel</tt> mailing list and
          try to find a consensus about which program will have to be
          renamed.  If a consensus cannot be reached, <em>both</em>
          programs must be renamed.
        </p>

        <p>
          Generally the following compilation parameters should be used:
          <example compact="compact">
CC = gcc
CFLAGS = -O2 -Wall # sane warning options vary between programs
LDFLAGS = # none
install -s # (or use strip on the files in debian/tmp)
          </example></p>

        <p>
          Note that by default all installed binaries should be stripped,
          either by using the <tt>-s</tt> flag to
          <prgn>install</prgn>, or by calling <prgn>strip</prgn> on
          the binaries after they have been copied into
          <tt>debian/tmp</tt> but before the tree is made into a
          package.</p>

        <p>
          The <tt>-N</tt> flag should not be used.  On <tt>a.out</tt>
          systems it may have been useful for some very small
          binaries, but for ELF it has no good effect.</p>

        <p>
          Debugging symbols are useful for error diagnosis,
          investigation of core dumps (which may be submitted by users
          in bug reports), or testing and developing the software.
          Therefore it is recommended to support building the package
          with debugging information through the following interface:
          If the environment variable <tt>DEB_BUILD_OPTIONS</tt>
          contains the string <tt>debug</tt>, compile the software
          with debugging information (usually this involves adding the
          <tt>-g</tt> flag to <tt>CFLAGS</tt>).  This allows the
          generation of a build tree with debugging information.  If
          the environment variable <tt>DEB_BUILD_OPTIONS</tt> contains
          the string <tt>nostrip</tt>, do not strip the files at
          installation time.  This allows one to generate a package
          with debugging information included.
          <footnote>
            <p>
              Rationale: Using <tt>-g</tt> by default causes wasted
              CPU cycles since the information is stripped away
              anyway; this can have a significant impact on the
              efficiency of the autobuilders.  Having a standard way
              to build a debugging variant also makes it easier to
              build debugging bins and libraries since it provides a
              documented way of getting this type of build; one does
              not have to manually edit <tt>debian/rules</tt> or
              <tt>Makefile</tt>s.
            </p>
          </footnote>
          The following makefile snippet is an example of how one may
          test for either condition; you will probably have to massage
          this example in order to make it work for your package.
          <example compact="compact">
CFLAGS = -O2 -Wall
INSTALL = install
INSTALL_FILE    = $(INSTALL) -p    -o root -g root  -m  644
INSTALL_PROGRAM = $(INSTALL) -p    -o root -g root  -m  755
INSTALL_SCRIPT  = $(INSTALL) -p    -o root -g root  -m  755
INSTALL_DIR     = $(INSTALL) -p -d -o root -g root  -m  755

ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
endif
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
          </example>
        </p>

        <p>
          It is up to the package maintainer to decide what
          compilation options are best for the package.  Certain
          binaries (such as computationally-intensive programs) will
          function better with certain flags (<tt>-O3</tt>, for
          example); feel free to use them.  Please use good judgment
          here.  Don't use flags for the sake of it; only use them
          if there is good reason to do so.  Feel free to override
          the upstream author's ideas about which compilation
          options are best: they are often inappropriate for our
          environment.</p></sect>


      <sect>
        <heading>Libraries</heading>

        <p>
          All libraries must have a shared version in the
          <tt>lib*</tt> package and a static version in the
          <tt>lib*-dev</tt> package.  The shared version must be
          compiled with <tt>-fPIC</tt>, and the static version must
          not be.  In other words, each <tt>*.c</tt> file will need to
          be compiled twice.</p>

        <p>
          You must specify the gcc option <tt>-D_REENTRANT</tt>
          when building a library (either static or shared) to make
          the library compatible with LinuxThreads.</p>

        <p>
          Note that all installed shared libraries should be
          stripped with
          <example compact="compact">
strip --strip-unneeded <var>your-lib</var>
          </example>
          (The option <tt>--strip-unneeded</tt> makes
          <prgn>strip</prgn> remove only the symbols which aren't
          needed for relocation processing.)  Shared libraries can
          function perfectly well when stripped, since the symbols for
          dynamic linking are in a separate part of the ELF object
          file.
          <footnote>
            <p>
              You might also want to use the options
              <tt>--remove-section=.comment</tt> and
              <tt>--remove-section=.note</tt> on both shared libraries
              and executables, and <tt>--strip-debug</tt> on static
              libraries.
            </p>
          </footnote>
        </p>

        <p>
          Note that under some circumstances it may be useful to
          install a shared library unstripped, for example when
          building a separate package to support debugging.
        </p>

        <p>
          An ever increasing number of packages are using
          <prgn>libtool</prgn> to do their linking.  The latest GNU
          libtools (>= 1.3a) can take advantage of the metadata in the
          installed <prgn>libtool</prgn> archive files (<tt>*.la</tt>
          files).  The main advantage of <prgn>libtool</prgn>'s
          <tt>.la</tt> files is that it allows <prgn>libtool</prgn> to
          store and subsequently access metadata with respect to the
          libraries it builds.  <prgn>libtool</prgn> will search for
          those files, which contain a lot of useful information about
          a library (such as library dependency information for static
          linking).  Also, they're <em>essential</em> for programs
          using <tt>libltdl</tt>.
          <footnote>
            <p>
              Although <prgn>libtool</prgn> is fully capable of
              linking against shared libraries which don't have
              <tt>.la</tt> files, as it is a mere shell script it can
              add considerably to the build time of a
              <prgn>libtool</prgn>-using package if that shell script
              has to derive all this information from first principles
              for each library every time it is linked.  With the
              advent of <prgn>libtool</prgn> version 1.4 (and to a
              lesser extent <prgn>libtool</prgn> version 1.3), the
              <tt>.la</tt> files will also store information about
              inter-library dependencies which cannot necessarily be
              derived after the <tt>.la</tt> file is deleted.
            </p>
          </footnote>
        </p>

        <p>
          Packages that use <prgn>libtool</prgn> to create shared
          libraries should include the <tt>.la</tt> files in the
          <tt>-dev</tt> package, unless the package relies on
          <tt>libtool</tt>'s <tt>libltdl</tt> library, in which case
          the <tt>.la</tt> files must go in the run-time library
          package.
        </p>

        <p>
          You must make sure that you use only released versions of
          shared libraries to build your packages; otherwise other
          users will not be able to run your binaries
          properly. Producing source packages that depend on
          unreleased compilers is also usually a bad
          idea.
        </p>
      </sect>

      <sect>
        <heading>Shared libraries</heading>

        <p>
          Packages involving shared libraries should be split up
          into several binary packages.</p>

        <p>
          For a straightforward library which has a development
          environment and a runtime kit including just shared
          libraries you need to create two packages:
          <tt><var>libraryname</var><var>soversion</var></tt>, where
          <tt><var>soversion</var></tt> is the version number in the
          soname of the shared library
          <footnote>
            <p>
              The soname is the shared object name: it's the thing
              that has to match exactly between building an executable
              and running it for the dynamic linker to be able run the
              program.  For example, if the soname of the library is
              <tt>libfoo.so.6</tt>, the library package would be
              called <tt>libfoo6</tt>.
            </p>
          </footnote>
          and <tt><var>libraryname</var><var>soversion</var>-dev</tt>.
        </p>

        <p>
          If you prefer only to support one development version at a
          time you may name the development package
          <tt><var>libraryname</var>-dev</tt>; otherwise you may need
          to use <prgn>dpkg</prgn>'s Conflicts mechanism (see <ref
          id="conflicts">) to ensure that the user only installs one
          development version at a time (as different development
          versions are likely to have the same header files in them,
          which would cause a filename clash if both were installed).
          Typically the development version should also have an exact
          version dependency on the runtime library, to make sure that
          compilation and linking happens correctly.  The
          <tt>${Source-Version}</tt> substitution variable can be
          useful for this purpose.
        </p>

        <p>
          Packages which use the shared library should have a
          dependency on the name of the shared library package,
          <tt><var>libraryname</var><var>soversion</var></tt>.  When
          the soname changes you can have both versions of the library
          installed while migrating from the old library to the new.
        </p>

        <p>
          If your package has some run-time support programs which use
          the shared library you must not put them in the shared
          library package.  If you do that then you won't be able to
          install several versions of the shared library without
          getting filename clashes.  Instead, either create a third
          package for the runtime binaries (this package might
          typically be named <tt><var>libraryname</var>-runtime</tt>;
          note the absence of the <var>soversion</var> in the package
          name), or if the development package is small you may
          include them in there.
        </p>

        <p>
          If you have several shared libraries built from the same
          source tree you may lump them all together into a single
          shared library package, provided that you change all of
          their sonames at once (so that you don't get filename
          clashes if you try to install different versions of the
          combined shared libraries package).
        </p>

        <p>
          Shared libraries should not be installed executable, since
          the dynamic linker does not require this and trying to
          execute a shared library usually results in a core dump.
        </p>
      </sect>

      <sect id="scripts">
        <heading>Scripts</heading>

        <p>
          All command scripts, including the package maintainer
          scripts inside the package and used by <prgn>dpkg</prgn>,
          should have a <tt>#!</tt> line naming the shell to be used
          to interpret them.</p>

        <p>
          In the case of Perl scripts this should be
          <tt>#!/usr/bin/perl</tt>.</p>

        <p>
          Shell scripts (<prgn>sh</prgn> and <prgn>bash</prgn>)
          should almost certainly start with <tt>set -e</tt> so that
          errors are detected.  Every script should use
          <tt>set -e</tt> or check the exit status of <em>every</em>
          command.</p>

        <p>
          The standard shell interpreter <tt>/bin/sh</tt> can be a
          symbolic link to any POSIX compatible shell, if <tt>echo
          -n</tt> does not generate a newline.
          <footnote>
            <p>
              Debian policy specifies POSIX behavior for
              <tt>/bin/sh</tt>, but <tt>echo -n</tt> has widespread
              use in the Linux community (in particular including this
              policy, the Linux kernel source, many Debian scripts,
              etc.).  This <tt>echo -n</tt> mechanism is valid but not
              required under POSIX, hence this explicit addition.
              Also, rumour has it that this shall be mandated under
              the LSB anyway.
            </p>
          </footnote>
          Thus, shell scripts specifying <tt>/bin/sh</tt> as
          interpreter should only use POSIX features. If a script
          requires non-POSIX features from the shell interpreter, the
          appropriate shell must be specified in the first line of the
          script (e.g., <tt>#!/bin/bash</tt>) and the package must
          depend on the package providing the shell (unless the shell
          package is marked `Essential', as in the case of
          <prgn>bash</prgn>).
        </p>

        <p>
          You may wish to restrict your script to POSIX features when
          possible so that it may use <tt>/bin/sh</tt> as its
          interpreter. If your script works with <prgn>ash</prgn>,
          it's probably POSIX compliant, but if you are in doubt, use
          <tt>/bin/bash</tt>.
        </p>

        <p>
          Perl scripts should check for errors when making any
          system calls, including <tt>open</tt>, <tt>print</tt>,
          <tt>close</tt>, <tt>rename</tt> and <tt>system</tt>.
        </p>

        <p>
          <prgn>csh</prgn> and <prgn>tcsh</prgn> should be avoided as
          scripting languages.  See <em>Csh Programming Considered
          Harmful</em>, one of the <tt>comp.unix.*</tt> FAQs, which
          can be found at <url
          id="http://language.perl.com/versus/csh.whynot">.
          <footnote>
            <p>
              It can also be found on
              <url id="http://www.cpan.org/doc/FMTEYEWTK/versus/csh.whynot">
              or on the ftp site <ftpsite>ftp.cpan.org</ftpsite> as
              <ftppath>/pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot</ftppath>.
              </p>
          </footnote>
          If an upstream package comes with <prgn>csh</prgn> scripts
          then you must make sure that they start with
          <tt>#!/bin/csh</tt> and make your package depend on the
          <prgn>c-shell</prgn> virtual package.
        </p>

        <p>
          Any scripts which create files in world-writeable
          directories (e.g., in <tt>/tmp</tt>) must use a
          mechanism which will fail if a file with the same name
          already exists.</p>

        <p>
          The Debian base distribution provides the
          <prgn>tempfile</prgn> and <prgn>mktemp</prgn> utilities
          for use by scripts for this purpose.</p></sect>


      <sect>
        <heading>Symbolic links</heading>

        <p>
          In general, symbolic links within a top-level directory
          should be relative, and symbolic links pointing from one
          top-level directory into another should be absolute. (A
          top-level directory is a sub-directory of the root
          directory <tt>/</tt>.)</p>

        <p>
          In addition, symbolic links should be specified as short as
          possible, i.e., link targets like <tt>foo/../bar</tt> are
          deprecated.</p>

        <p>
          Note that when creating a relative link using
          <prgn>ln</prgn> it is not necessary for the target of the
          link to exist relative to the working directory you're
          running <prgn>ln</prgn> from, nor is it necessary to change
          directory to the directory where the link is to be made.
          Simply include the string that should appear as the target
          of the link (this will be a pathname relative to the
          directory in which the link resides) as the first argument
          to <prgn>ln</prgn>.</p>

        <p>
          For example, in your <prgn>Makefile</prgn> or
          <tt>debian/rules</tt>, you can do things like:
          <example compact="compact">
ln -fs gcc $(prefix)/bin/cc
ln -fs gcc debian/tmp/usr/bin/cc
ln -fs ../sbin/sendmail $(prefix)/bin/runq
ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
          </example></p>

        <p>
          A symbolic link pointing to a compressed file should always
          have the same file extension as the referenced file. (For
          example, if a file <tt>foo.gz</tt> is referenced by a
          symbolic link, the filename of the link has to end with
          `<tt>.gz</tt>' too, as in <tt>bar.gz</tt>.)
        </p>
      </sect>

      <sect>
        <heading>Device files</heading>

        <p>
          Packages must not include device files in the package file
          tree.</p>

        <p>
          If a package needs any special device files that are not
          included in the base system, it must call
          <prgn>MAKEDEV</prgn> in the <prgn>postinst</prgn> script,
          after asking the user for permission to do so.</p>

        <p>
          Packages must not remove any device files in the
          <prgn>postrm</prgn> or any other script. This is left to the
          system administrator.</p>

        <p>
          Debian uses the serial devices
          <tt>/dev/ttyS*</tt>. Programs using the old
          <tt>/dev/cu*</tt> devices should be changed to use
          <tt>/dev/ttyS*</tt>.</p>
      </sect>

      <sect id="config files">
        <heading>Configuration files</heading>
        <sect1>
          <heading>Definitions</heading>
          <p>
            <taglist>
              <tag>configuration file</tag>
              <item>
                <p>
                  A file that affects the operation of a program, or
                  provides site- or host-specific information, or
                  otherwise customizes the behavior of a program.
                  Typically, configuration files are intended to be
                  modified by the system administrator (if needed or
                  desired) to conform to local policy or to provide
                  more useful site-specific behavior.
                </p>
              </item>

              <tag><tt>conffile</tt></tag>
              <item>
                <p>
                  A file listed in a package's <tt>conffiles</tt>
                  file, and is treated specially by <prgn>dpkg</prgn>
                  (see <ref id="configdetails">).
                </p>
              </item>
            </taglist>
          </p>

          <p>
            The distinction between these two is important; they are
            not interchangeable concepts. Almost all
            <tt>conffile</tt>s are configuration files, but many
            configuration files are not <tt>conffiles</tt>.
          </p>

          <p>
            Note that a script that embeds configuration information
            (such as most of the files in <tt>/etc/default</tt> and
            <tt>/etc/cron.{daily,weekly,monthly}</tt>) is de-facto a
            configuration file and should be treated as such.
          </p>
        </sect1>

        <sect1>
          <heading>Location</heading>
          <p>
            Any configuration files created or used by your package
            must reside in <tt>/etc</tt>. If there are several you
            should consider creating a subdirectory of <tt>/etc</tt>
            named after your package.</p>

          <p>
            If your package creates or uses configuration files
            outside of <tt>/etc</tt>, and it is not feasible to modify
            the package to use the <tt>/etc</tt>, you should still put
            the files in <tt>/etc</tt> and create symbolic links to
            those files from the location that the package
            requires.</p>
        </sect1>

        <sect1>
          <heading>Behavior</heading>
          <p>
            Configuration file handling must conform to the following
            behavior:
            <list compact="compact">
              <item>
                <p>
                  local changes must be preserved during a package
                  upgrade, and
                </p>
              </item>
              <item>
                <p>
                  configuration files must be preserved when the
                  package is removed, and only deleted when the
                  package is purged.
                </p>
              </item>
            </list>
          </p>

          <p>
            The easy way to achieve this behavior is to make the
            configuration file a <tt>conffile</tt>. This is
            appropriate only if it is possible to distribute a default
            version that will work for most installations, although
            some system administrators may choose to modify it. This
            implies that the default version will be part of the
            package distribution, and must not be modified by the
            maintainer scripts during installation (or at any other
            time).
          </p>

          <p>
            In order to ensure that local changes are preserved
            correctly, no package may contain or make hard links to
            conffiles.
            <footnote>
              <p>
                Rationale: There are two problems with hard links.
                The first is that some editors break the link while
                editing one of the files, so that the two files may
                unwittingly become unlinked and different.  The second
                is that <prgn>dpkg</prgn> might break the hard link
                while upgrading <tt>conffile</tt>s.
              </p>
            </footnote>
            </p>

            <p>
            The other way to do it is via the maintainer scripts.  In
            this case, the configuration file must not be listed as a
            <tt>conffile</tt> and must not be part of the package
            distribution. If the existence of a file is required for
            the package to be sensibly configured it is the
            responsibility of the package maintainer to provide
            maintainer scripts which correctly create, update and
            maintain the file and remove it on purge.  (See <ref
            id="maintainerscripts"> for more information.)  These
            scripts must be idempotent (i.e., must work correctly if
            <prgn>dpkg</prgn> needs to re-run them due to errors
            during installation or removal), must cope with all the
            variety of ways <prgn>dpkg</prgn> can call maintainer
            scripts, must not overwrite or otherwise mangle the user's
            configuration without asking, must not ask unnecessary
            questions (particularly during upgrades), and otherwise be
            good citizens.
          </p>

          <p>
            The scripts are not required to configure every possible
            option for the package, but only those necessary to get
            the package running on a given system. Ideally the
            sysadmin should not have to do any configuration other
            than that done (semi-)automatically by the
            <prgn>postinst</prgn> script.
          </p>

          <p>
            A common practice is to create a script called
            <tt><var>package</var>-configure</tt> and have the
            package's <prgn>postinst</prgn> call it if and only if the
            configuration file does not already exist.  In certain
            cases it is useful for there to be an example or template
            file which the maintainer scripts use.  Such files should
            be in <tt>/usr/share/<var>package</var></tt> or
            <tt>/usr/lib/<var>package</var></tt> (depending on whether
            they are architecture-independent or not).  There should
            be symbolic links to them from
            <tt>/usr/share/doc/<var>package</var>/examples</tt> if
            they are examples, and should be perfectly ordinary
            <prgn>dpkg</prgn>-handled files (<em>not</em>
            <tt>conffiles</tt>).
          </p>

          <p>
            These two styles of configuration file handling must
            not be mixed, for that way lies madness:
            <prgn>dpkg</prgn> will ask about overwriting the file
            every time the package is upgraded.
          </p>
        </sect1>

        <sect1>
          <heading>Sharing configuration files</heading>
          <p>
            Packages which specify the same file as a
            <tt>conffile</tt> must be tagged as <em>conflicting</em>
            with each other.  (This is an instance of the general rule
            about not sharing files.  Note that neither alternatives
            nor diversions are likely to be appropriate in this case.)
          </p>

          <p>
            The maintainer scripts must not alter a <tt>conffile</tt>
            of <em>any</em> package, including the one the scripts
            belong to.
          </p>

          <p>
            If two or more packages use the same configuration file
            and it is reasonable for both to be installed at the same
            time, one of these packages must be defined as
            <em>owner</em> of the configuration file, i.e., it will be
            the package which handles that file as a configuration
            file.  Other packages that use the configuration file must
            depend on the owning package if they require the
            configuration file to operate. If the other package will
            use the configuration file if present, but is capable of
            operating without it, no dependency need be declared.</p>

          <p>
            If it is desirable for two or more related packages to
            share a configuration file <em>and</em> for all of the
            related packages to be able to modify that configuration
            file, then the following should be done:
            <enumlist compact="compact">
              <item>
                <p>
                  One of the related packages (the "owning" package)
                  will manage the configuration file with maintainer
                  scripts as described in the previous section.
                </p>
              </item>
              <item>
                <p>
                  The owning package should also provide a program
                  that the other packages may use to modify the
                  configuration file.
                </p>
              </item>
              <item>
                <p>
                  The related packages must use the provided program
                  to make any desired modifications to the
                  configuration file.  They should either depend on
                  the core package to guarantee that the configuration
                  modifier program is available or accept gracefully
                  that they cannot modify the configuration file if it
                  is not.  (This is in addition to the fact that the
                  configuration file may not even be present in the
                  latter scenario.)
                </p>
              </item>
            </enumlist>
          </p>

          <p>
            Sometimes it's appropriate to create a new package which
            provides the basic infrastructure for the other packages
            and which manages the shared configuration files.  (The
            <tt>sgml-base</tt> package is a good example.)
          </p>
        </sect1>

        <sect1>
          <heading>User configuration files ("dotfiles")</heading>

          <p>
            The files in <tt>/etc/skel</tt> will automatically be
            copied into new user accounts by <prgn>adduser</prgn>.
            No other program should reference the files in
            <tt>/etc/skel</tt>.
          </p>

          <p>
            Therefore, if a program needs a dotfile to exist in
            advance in <tt>$HOME</tt> to work sensibly, that dotfile
            should be installed in <tt>/etc/skel</tt> and treated as a
            configuration file.
          </p>

          <p>
            However, programs that require dotfiles in order to
            operate sensibly (dotfiles that they do not create
            themselves automatically, that is) are a bad thing.
            Furthermore, programs should be configured by the Debian
            default installation as behave as closely to the upstream
            default behaviour as possible.
          </p>

          <p>
            Therefore, if a program in a Debian package needs to be
            configured in some way in order to operate sensibly, that
            should be done using a site-wide configuration file placed
            in <tt>/etc</tt>.  Only if the program doesn't support a
            site-wide default configuration and the package maintainer
            doesn't have time to add it may a default per-user file be
            placed in <tt>/etc/skel</tt>.
          </p>

          <p>
            <tt>/etc/skel</tt> should be as empty as we can make it.
            This is particularly true because there is no easy (or
            necessarily desirable) mechanism for ensuring that the
            appropriate dotfiles are copied into the accounts of
            existing users when a package is installed.
          </p>
        </sect1>
      </sect>

      <sect>
        <heading>Log files</heading>
        <p>
          Log files should usually be named
          <tt>/var/log/<var>package</var>.log</tt>.  If you have many
          log files, or need a separate directory for permission
          reasons (<tt>/var/log</tt> is writable only by
          <tt>root</tt>), you should usually create a directory named
          <tt>/var/log/<var>package</var></tt> and place your log
          files there.
        </p>

        <p>
          Log files must be rotated occasionally so that they don't
          grow indefinitely; the best way to do this is to drop a log
          rotation configuration file into the directory
          <tt>/etc/logrotate.d</tt> and use the facilities provided by
          logrotate.
          <footnote>
            <p>
              The traditional approach to log files has been to set up
              <em>ad hoc</em> log rotation schemes using simple shell
              scripts and cron.  While this approach is highly
              customizable, it requires quite a lot of sysadmin work.
              Even though the original Debian system helped a little
              by automatically installing a system which can be used
              as a template, this was deemed not enough.
            </p>

            <p>
              The use of <prgn>logrotate</prgn>, a program developed
              by Red Hat, is better, as it centralizes log management.
              It has both a configuration file
              (<tt>/etc/logrotate.conf</tt>) and a directory where
              packages can drop their individual log rotation
              configurations (<tt>/etc/logrotate.d</tt>).
            </p>
          </footnote>
          Here is a good example for a logrotate config
          file (for more information see <manref name="logrotate"
            section="8">):
          <example compact="compact">
/var/log/foo/* {
rotate 12
weekly
compress
postrotate
/etc/init.d/foo force-reload
endscript
}
          </example>
          This rotates all files under <tt>/var/log/foo</tt>, saves 12
          compressed generations, and forces the daemon to reload its
          configuration information after the log rotation.
        </p>

        <p>
          Log files should be removed when the package is
          purged (but not when it is only removed).  This should be
          done by the <prgn>postrm</prgn> script when it is called
          with the argument <tt>purge</tt> (see <ref
          id="removedetails">).
        </p>
      </sect>

      <sect>
        <heading>Permissions and owners</heading>

        <p>
          The rules in this section are guidelines for general use.
          If necessary you may deviate from the details below.
          However, if you do so you must make sure that what is done
          is secure and you should try to be as consistent as possible
          with the rest of the system.  You should probably also
          discuss it on <prgn>debian-devel</prgn> first.
        </p>

        <p>
          Files should be owned by <tt>root.root</tt>, and made
          writable only by the owner and universally readable (and
          executable, if appropriate), that is mode 644 or 755.
        </p>

        <p>
          Directories should be mode 755 or (for group-writability)
          mode 2775.  The ownership of the directory should be
          consistent with its mode: if a directory is mode 2775, it
          should be owned by the group that needs write access to
          it.
        </p>

        <p>
          Setuid and setgid executables should be mode 4755 or 2755
          respectively, and owned by the appropriate user or group.
          They should not be made unreadable (modes like 4711 or
          2711 or even 4111); doing so achieves no extra security,
          because anyone can find the binary in the freely available
          Debian package; it is merely inconvenient.  For the same
          reason you should not restrict read or execute permissions
          on non-set-id executables.
        </p>

        <p>
          Some setuid programs need to be restricted to particular
          sets of users, using file permissions.  In this case they
          should be owned by the uid to which they are set-id, and by
          the group which should be allowed to execute them.  They
          should have mode 4754; again there is no point in making
          them unreadable to those users who must not be allowed to
          execute them.
        </p>

        <p>
          It is possible to arrange that the system administrator can
          reconfigure the package to correspond to their local
          security policy by changing the permissions on a binary:
          they can do this by using <prgn>dpkg-statoverride</prgn>, as
          described below.
          <footnote>
            <p>
              Ordinary files installed by <prgn>dpkg</prgn> (as
              opposed to <tt>conffile</tt>s and other similar objects)
              normally have their permissions reset to the distributed
              permissions when the package is reinstalled.  However,
              the use of <prgn>dpkg-statoverride</prgn> overrides this
              default behaviour.  If you use this method, you should
              remember to describe <prgn>dpkg-statoverride</prgn> in
              the package documentation; being a relatively new
              addition to Debian, it is probably not yet well-known.
            </p>
          </footnote>
          Another method you should consider is to create a group for
          people allowed to use the program(s) and make any setuid
          executables executable only by that group.
        </p>

        <p>
          If you need to create a new user or group for your package
          there are two possibilities.  Firstly, you may need to
          make some files in the binary package be owned by this
          user or group, or you may need to compile the user or
          group id (rather than just the name) into the binary
          (though this latter should be avoided if possible, as in
          this case you need a statically allocated id).</p>

        <p>
          If you need a statically allocated id, you must ask for a
          user or group id from the <tt>base-passwd</tt> maintainer,
          and must not release the package until you have been
          allocated one.  Once you have been allocated one you must
          either make the package depend on a version of the
          <tt>base-passwd</tt> package with the id present in
          <tt>/etc/passwd</tt> or <tt>/etc/group</tt>, or arrange for
          your package to create the user or group itself with the
          correct id (using <tt>adduser</tt>) in its
          <prgn>preinst</prgn> or <prgn>postinst</prgn>.  (Doing it in
          the <prgn>postinst</prgn> is to be preferred if it is
          possible, otherwise a pre-dependency will be needed on the
          <tt>adduser</tt> package.)
        </p>

        <p>
          On the other hand, the program might be able to determine
          the uid or gid from the user or group name at runtime, so
          that a dynamically allocated id can be used.  In this case
          you should choose an appropriate user or group name,
          discussing this on <prgn>debian-devel</prgn> and checking
          with the base system maintainer that it is unique and that
          they do not wish you to use a statically allocated id
          instead.  When this has been checked you must arrange for
          your package to create the user or group if necessary using
          <prgn>adduser</prgn> in the <prgn>preinst</prgn> or
          <prgn>postinst</prgn> script (again, the latter is to be
          preferred if it is possible).
        </p>

        <p>
          Note that changing the numeric value of an id associated
          with a name is very difficult, and involves searching the
          file system for all appropriate files.  You need to think
          carefully whether a static or dynamic id is required, since
          changing your mind later will cause problems.
        </p>

        <sect1><heading>The use of <prgn>dpkg-statoverride</prgn></heading>
          <p>
            This section is not intended as policy, but as a
            description of the use of <prgn>dpkg-statoverride</prgn>.
          </p>

          <p>
            <prgn>dpkg-statoverride</prgn> is a replacement for the
            deprecated <tt>suidmanager</tt> package.  Packages which
            previously used <tt>suidmanager</tt> should have a
            <tt>Conflicts: suidmanager (<< 0.50)</tt> entry (or even
            <tt>(<< 0.52)</tt>), and calls to <tt>suidregister</tt>
            and <tt>suidunregister</tt> should now be simply removed
            from the maintainer scripts.
          </p>

          <p>
            If a system administrator wishes to have a file (or
            directory or other such thing) installed with owner and
            permissions different from those in the distributed Debian
            package, he can use the <prgn>dpkg-statoverride</prgn>
            program to instruct <prgn>dpkg</prgn> to use the different
            settings every time the file is installed.  Thus the
            package maintainer should distribute the files with their
            normal permissions, and leave it for the system
            administrator to make any desired changes.  For example, a
            daemon which is normally required to be setuid root, but
            in certain situations could be used without being setuid,
            should be installed setuid in the <tt>.deb</tt>.  Then the
            local system administrator can change this if they wish.
            If there are two standard ways of doing it, the package
            maintainer can use <tt>debconf</tt> to find out the
            preference, and call <prgn>dpkg-statoverride</prgn> in the
            maintainer script if necessary to accommodate the system
            administrator's choice.
          </p>

          <p>
            Given the above, <prgn>dpkg-statoverride</prgn> is
            essentially a tool for system administrators and would not
            normally be needed in the maintainer scripts.  There is
            one type of situation, though, where calls to
            <prgn>dpkg-statoverride</prgn> would be needed in the
            maintainer scripts, and that involves packages which use
            dynamically allocated user or group ids.  In such a
            situation, something like the following idiom can be very
            helpful in the package's <prgn>postinst</prgn>, where
            <tt>sysuser</tt> is a dynamically allocated id:
            <example>
for i in /usr/bin/foo /usr/sbin/bar
do
  if ! dpkg-statoverride --list $i >/dev/null
  then
    dpkg-statoverride --update --add sysuser root 4755 $i
  fi
done
            </example>
            The corresponding <tt>dpkg-statoverride --remove</tt>
            calls can then be made unconditionally when the package is
            purged.
          </p>
        </sect1>
      </sect>
    </chapt>

    <chapt id="customized-programs">
      <heading>Customized programs</heading>

      <sect id="arch-spec">
        <heading>Architecture specification strings</heading>

        <p>
          If a program needs to specify an <em>architecture specification
            string</em> in some place, the following format should be used:
          <example compact="compact">
<var>arch</var>-<var>os</var>
          </example>
          where <tt><var>arch</var></tt> is one of the following:
          <tt>i386</tt>, <tt>alpha</tt>, <tt>arm</tt>, <tt>m68k</tt>,
          <tt>powerpc</tt>, <tt>sparc</tt> and <tt><var>os</var></tt>
          is one of: <tt>linux</tt>, <tt>gnu</tt>.  Use of
          <tt>gnu</tt> in this string is reserved for the GNU/Hurd
          operating system.
        </p>

        <p>
          Note, that we don't want to use
          <tt><var>arch</var>-debian-linux</tt> to apply to the rule
          `architecture-vendor-os' since this would make our programs
          incompatible with other Linux distributions.  Also note that
          we don't use <tt><var>arch</var>-unknown-linux</tt>, since
          the <tt>unknown</tt> does not look very good.
        </p>
      </sect>

      <sect>
        <heading>Daemons</heading>

        <p>
          The configuration files <tt>/etc/services</tt>,
          <tt>/etc/protocols</tt>, and <tt>/etc/rpc</tt> are managed
          by the <prgn>netbase</prgn> package and may not be modified
          by other packages.</p>

        <p>
          If a package requires a new entry in one of these files, the
          maintainer should get in contact with the
          <prgn>netbase</prgn> maintainer, who will add the entries
          and release a new version of the <prgn>netbase</prgn>
          package.</p>

        <p>
          The configuration file <tt>/etc/inetd.conf</tt> must not be
          modified by the package's scripts except via the
          <prgn>update-inetd</prgn> script or the
          <prgn>DebianNet.pm</prgn> Perl module.</p>

        <p>
          If a package wants to install an example entry into
          <tt>/etc/inetd.conf</tt>, the entry must be preceded with
          exactly one hash character (<tt>#</tt>). Such lines are
          treated as `commented out by user' by the
          <prgn>update-inetd</prgn> script and are not changed or
          activated during a package updates.</p></sect>


      <sect>
        <heading>Using pseudo-ttys and modifying wtmp, utmp and lastlog</heading>

        <p>
          Some programs need to create pseudo-ttys. This should be done
          using Unix98 ptys if the C library supports it. The resulting
          program must not be installed setuid root, unless that
          is required for other functionality.
        </p>

        <p>
          The files <tt>/var/run/utmp</tt>, <tt>/var/log/wtmp</tt> and
          <tt>/var/log/lastlog</tt> must be installed writeable by
          group utmp.  Programs who need to modify those files must
          be installed setgid utmp.
        </p>
      </sect>

      <sect>
        <heading>Editors and pagers</heading>

        <p>
          Some programs have the ability to launch an editor or pager
          program to edit or display a text document. Since there are
          lots of different editors and pagers available in the Debian
          distribution, the system administrator and each user should
          have the possibility to choose his/her preferred editor and
          pager.</p>

        <p>
          In addition, every program should choose a good default
          editor/pager if none is selected by the user or system
          administrator.</p>

        <p>
          Thus, every program that launches an editor or pager must
          use the EDITOR or PAGER environment variables to determine
          the editor/pager the user wants to get started. If these
          variables are not set, the programs <tt>/usr/bin/editor</tt>
          and <tt>/usr/bin/pager</tt> should be used, respectively.</p>

        <p>
          These two files are managed through `alternatives.' That is,
          every package providing an editor or pager must call the
          <prgn>update-alternatives</prgn> script to register these
          programs.</p>

        <p>
          If it is very hard to adapt a program to make us of the
          EDITOR and PAGER variables, that program may be configured
          to use <tt>/usr/bin/sensible-editor</tt> and
          <tt>/usr/bin/sensible-pager</tt> as editor or pager program,
          respectively. These are two scripts provided in the Debian
          base system that check the EDITOR and PAGER variables and
          launch the appropriate program or fall back to
          <tt>/usr/bin/editor</tt> and <tt>/usr/bin/pager</tt>,
          automatically.</p>

        <p>
          A program may also use the VISUAL environment variable to
          determine the user's choice of editor. If it exists, it
          should take precedence over EDITOR. This is in fact what
          <tt>/usr/bin/sensible-editor</tt> does.</p>

        <p>
          It is not required for a package to depend on
          `editor' and `pager', nor is it required for a package to
          provide such virtual packages.
          <footnote>
            <p>
              The Debian base system already provides an editor and
              a pager program,
            </p>
          </footnote>
        </p>

      </sect>


      <sect id="web-appl">
        <heading>Web servers and applications</heading>

        <p>
          This section describes the locations and URLs that should
          be used by all web servers and web application in the Debian
          system.</p>

        <p>
          <enumlist>
            <item>
              <p>Cgi-bin executable files are installed in the
                directory
                <example compact="compact">
/usr/lib/cgi-bin/<var>cgi-bin-name</var>
                </example>
                and should be referred to as
                <example compact="compact">
http://localhost/cgi-bin/<var>cgi-bin-name</var>
                </example>
              </p>
            </item>

            <item><p>Access to html documents</p>

              <p>
                Html documents for a package are stored in
                <tt>/usr/share/doc/<var>package</var></tt> but should
                be accessed via symlinks as
                <tt>/usr/doc/<var>package</var></tt><footnote> for
                    backward compatibility, see <ref id="usrdoc"></footnote>
                and can be referred to as
                <example compact="compact">
http://localhost/doc/<var>package</var>/<var>filename</var>
                </example>
              </p>
            </item>

            <item><p>Web Document Root</p>

              <p>
                Web Applications should try to avoid storing files in
                the Web Document Root.  Instead they should use the
                /usr/share/doc/<var>package</var> directory for
                documents and register the Web Application via the
                menu package. If access to the web-root is unavoidable
                then use
                <example compact="compact">
/var/www
                </example>
                as the Document Root. This might be just a
                symbolic link to the location where the sysadmin has
                put the real document root.</p>
            </item>

          </enumlist></p></sect>


      <sect id="mail-transport-agents">
        <heading>Mail transport, delivery and user agents</heading>

        <p>
          Debian packages which process electronic mail, whether
          mail-user-agents (MUAs) or mail-transport-agents (MTAs),
          must make sure that they are compatible with the
          configuration decisions below.  Failure to do this may
          result in lost mail, broken <tt>From:</tt> lines, and other
          serious brain damage!</p>

        <p>
          The mail spool is <tt>/var/mail</tt> and the interface
          to send a mail message is <tt>/usr/sbin/sendmail</tt> (as
          per the FHS).  On older systems, the mail spool may be
          physically located in /var/spool/mail, but all access to the
          mail spool should be via the /var/mail symlink. The mail
          spool is part of the base system and not part of the MTA
          package.
        </p> 

        <p>
          All Debian MUAs, MTAs, MDAs and other mailbox accessing
          programs (like IMAP daemons) must lock the mailbox in an
          NFS-safe way. This means that <tt>fcntl()</tt> locking must
          be combined with dot locking.  To avoid deadlocks, a
          program should use <tt>fcntl()</tt> first and dot locking
          after this or alternatively implement the two locking
          methods in a non blocking way<footnote>
            <p>
              If it is not possible to establish both locks, the
              system shouldn't wait for the second lock to be
              established, but remove the first lock, wait a (random)
              time, and start over locking again.</p>
          </footnote>. Using the functions <tt>maillock</tt> and
          <tt>mailunlock</tt> provided by the
          <tt>liblockfile*</tt><footnote>
            <p>
              <tt>liblockfile</tt> version &gt;&gt;1.01</p>
          </footnote> packages is the recommended way to realize this.
        </p>

        <p>
          Mailboxes are generally 660 <tt><var>user</var>.mail</tt>
          unless the user has chosen otherwise.  A MUA may remove a
          mailbox (unless it has nonstandard permissions) in which
          case the MTA or another MUA must recreate it if needed.
          Mailboxes must be writable by group mail.</p>

        <p>
          The mail spool is 2775 <tt>root.mail</tt>, and MUAs should
          be setgid mail to do the locking mentioned above (and
          must obviously avoid accessing other users' mailboxes
          using this privilege).</p>

        <p>
          <tt>/etc/aliases</tt> is the source file for the system mail
          aliases (e.g., postmaster, usenet, etc.), it is the one
          which the sysadmin and <prgn>postinst</prgn> scripts may edit.
          After <tt>/etc/aliases</tt> is edited the program or human
          editing it must call <prgn>newaliases</prgn>.  All MTA
          packages must come with a <prgn>newaliases</prgn> program,
          even if it does nothing, but older MTA packages do not do
          this so programs should not fail if <prgn>newaliases</prgn>
          cannot be found.</p>

        <p>
          The convention of writing <tt>forward to
            <var>address</var></tt> in the mailbox itself is not
          supported.  Use a <tt>.forward</tt> file instead.</p>

        <p>
          The <prgn>rmail</prgn> program used by UUCP
          for incoming mail should be  <tt>/usr/sbin/rmail</tt>.
          Likewise, <prgn>rsmtp</prgn>, for receiving
          batch-SMTP-over-UUCP, should be <tt>/usr/sbin/rsmtp</tt> if it
          is supported.</p>

        <p>
          If you need to know what name to use (for example) on
          outgoing news and mail messages which are generated locally,
          you should use the file <tt>/etc/mailname</tt>.  It will
          contain the portion after the username and <tt>@</tt> (at)
          sign for email addresses of users on the machine (followed
          by a newline).</p>

        <p>
          A package should check for the existence of this file.  If
          it exists it should use it without comment. (An MTA's
          prompting configuration script may wish to prompt the user
          even if it finds this file exists.) If it does not exist it
          should prompt the user for the value and store it in
          <tt>/etc/mailname</tt> as well as using it in the package's
          configuration.  The prompt should make it clear that the
          name will not just be used by that package.  For example, in
          this situation the INN package says:
          <example compact="compact">
Please enter the `mail name' of your system.  This is the
hostname portion of the address to be shown on outgoing
news and mail messages.  The default is
<var>syshostname</var>, your system's host name.  Mail
name [`<var>syshostname</var>']:
          </example>
          where <var>syshostname</var> is the output of <tt>hostname
            --fqdn</tt>.
        </p>
      </sect>

      <sect>
        <heading>News system configuration</heading>

        <p>
          All the configuration files related to the NNTP (news)
          servers and clients should be located under
          <tt>/etc/news</tt>.</p>

        <p>
          There are some configuration issues that apply to a number
          of news clients and server packages on the machine. These
          are:

          <taglist>
            <tag>/etc/news/organization</tag>
            <item><p>A string which should appear as the
                organization header for all messages posted
                by NNTP clients on the machine</p></item>

            <tag>/etc/news/server</tag>
            <item><p>Contains the FQDN of the upstream NNTP
                server, or localhost if the local machine is
                an NNTP server.</p></item>
          </taglist>

          Other global files may be added as required for cross-package news
          configuration.</p></sect>


      <sect>
        <heading>Programs for the X Window System</heading>

        <p>
          <em>Programs that may be configured with support for the X Window
            System</em> must be configured to do so and must declare any
          package dependencies necessary to satisfy their runtime
          requirements when using the X Window System, unless the package
          in question is of standard or higher priority, in which case
          X-specific binaries may be split into a separate package, or
          alternative versions of the package with X support may be
          provided.
        </p>


        <p>
          <em>Packages which provide an X server</em> that, directly or
          indirectly, communicates with real input and display hardware
          should declare in their control data that they provide the
          virtual package <tt>xserver</tt>.
          <footnote>
            <p>
              This implements current practice, and provides an actual
              policy for usage of the "xserver" virtual package which
              appears in the virtual packages list.  In a nutshell, X
              servers that interface directly with the display and input
              hardware or via another subsystem (e.g., GGI) should provide
              xserver.  Things like Xvfb, Xnest, and Xprt should not.
            </p>
          </footnote>
        </p>

        <p>
          <em>Packages that provide a terminal emulator</em> for the X
          Window System which support a terminal type with a terminfo
          description provided in the <tt>ncurses-base</tt> package
          should declare in their control data that they provide the
          virtual package <tt>x-terminal-emulator</tt>.  They should
          also register themselves as an alternative for
          <tt>/usr/bin/x-terminal-emulator</tt>, with a priority of
          20.
        </p>

        <p>
          <em>Packages that provide window managers</em> should declare in
          their control data that they provide the virtual package
          <tt>x-window-manager</tt>.  They should also register themselves as an
          alternative for <tt>/usr/bin/x-window-manager</tt>, with a priority
          calculated as follows:
          <list compact="compact">
            <item>Start with a priority of 20.</item>
            <item>If the window manager supports the Debian menu system,
                add 20 points if this support is available in the
                package's default configuration (i.e., no
                configuration files belonging to the system or user
                have to be edited to activate the feature); if
                configuration files must be modified, add only 10
                points.</item>
            <item>If the window manager permits the X session to be
                restarted using a <em>different</em> window manager
                (without killing the X server) in its default
                configuration, add 10 points; otherwise add
                none.</item>
          </list>
        </p>

        <p>
          <em>Packages that provide fonts for the X Window System</em>
          must do a number of things to ensure that they are both
          available without modification of the X or font server
          configuration, and that they do not corrupt files used by
          other font packages to register information about themselves.
          <enumlist>
            <item>
                Fonts of any type supported by the X Window System
                should be be in a separate binary package from any
                executables, libraries, or documentation (except that
                specific to the fonts shipped); if a program or
                library is <em>unusable</em> without one or more
                specific fonts, the package containing the program or
                library should declare a dependency on the package(s)
                containing the font(s) it requires.
            </item>
            <item>
                BDF fonts should be converted to PCF fonts with the
                <tt>bdftopcf</tt> utility (available in the
                <tt>xutils</tt> package), <tt>gzip</tt>ped, and
                placed in a directory that corresponds to their
                resolution:
                <list compact="compact">
                  <item>
                      100 dpi fonts should be placed in
                      <tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>.
                  </item>
                  <item>
                      75 dpi fonts should be placed in
                      <tt>/usr/X11R6/lib/X11/fonts/75dpi/</tt>.
                  </item>
                  <item>
                      Character-cell fonts, cursor fonts, and other
                      low-resolution fonts should be placed in
                      <tt>/usr/X11R6/lib/X11/fonts/misc/</tt>.
                  </item>
                </list>
            </item>
            <item>
                Speedo fonts should be placed in
                <tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt>.
            </item>
            <item>
                Type 1 fonts should be placed in
                <tt>/usr/X11R6/lib/X11/fonts/Type1/</tt>.  If font
                metric files are available, they may be placed here as
                well.
            </item>
            <item>
                Subdirectories of <tt>/usr/X11R6/lib/X11/fonts/</tt>
                other than those listed above should be neither created nor
                used.  (The <tt>PEX</tt> and <tt>cyrillic</tt> directories are
                excepted for historical reasons, but installation of files into
                these directories remains discouraged.)
            </item>
            <item>
                Font packages may, instead of placing files directly in
                the X font directories listed above, provide symbolic links in
                the font directory which point to the files' actual location
                in the filesystem.  Such a location should comply with the
                FHS.
            </item>
            <item>
                Font packages should not contain both 75dpi and 100dpi
                versions of a font.  If both are available, they should be
                provided in separate binary packages with "-75dpi" or "-100dpi"
                appended to the names of the packages containing the
                corresponding fonts.
            </item>
            <item>
                Fonts destined for the <tt>misc</tt> subdirectory should
                not be included in the same package as 75dpi or 100dpi fonts;
                instead, they should be provided in a separate package with
                "-misc" appended to its name.
            </item>
            <item>
                Font packages <em>must not</em> provide the files
                <tt>fonts.dir</tt>, <tt>fonts.alias</tt>, or
                <tt>fonts.scale</tt> in a font directory.
                <list compact="compact">
                  <item>
                      <tt>fonts.dir</tt> files must not be provided at
                      all.
                  </item>
                  <item>
                      <tt>fonts.alias</tt> and <tt>fonts.scale</tt>
                      files, if needed, should be provided in the
                      directory
                      <tt>/etc/X11/fonts/<em>fontdir</em>/<em>package</em>.<em>extension</em></tt>,
                      where <em>fontdir</em> is the name of the
                      subdirectory of
                      <tt>/usr/X11R6/lib/X11/fonts/</tt> where the
                      package's corresponding fonts are stored (e.g.,
                      <tt>75dpi</tt> or <tt>misc</tt>),
                      <em>package</em> is the name of the package that
                      provides these fonts, and <em>extension</em> is
                      either <tt>scale</tt> or <tt>alias</tt>,
                      whichever corresponds to the file
                      contents.
                  </item>
                </list>
            </item>
            <item>
                Font packages must declare a dependency on
                <tt>xutils</tt> and, in the package
                post-installation and post-removal scripts, invoke the
                <tt>mkfontdir</tt> command on each directory into
                which they installed fonts.
            </item>
            <item>
                Font packages that provide one or more
                <tt>fonts.scale</tt> files as described above must declare a
                versioned dependency on <tt>xutils (&gt;=
                  4.0.2)</tt> and invoke <tt>update-fonts-scale</tt> on each
                directory into which they installed fonts
                <em>before</em> invoking <tt>mkfontdir</tt> on that
                directory.  This invocation must occur in both the
                post-installation and post-removal scripts.
            </item>
            <item>
                Font packages that provide one or more
                <tt>fonts.alias</tt> files as described above must
                declare a versioned dependency on <tt>xutils
                  (&gt;= 4.0.2)</tt> and, in the package
                post-installation and post-removal scripts, invoke
                <tt>update-fonts-alias</tt> on each directory into
                which they installed fonts.
            </item>
            <item>
                Font packages must not provide alias names for the
                fonts they include which collide with alias names already in
                use by fonts already packaged.
            </item>
            <item>
                Font packages must not provide fonts with the same XLFD
                registry name as another font already packaged.
            </item>
          </enumlist>
        </p>

        <p>
          <em>Application defaults</em> files must be installed in the
          directory <tt>/etc/X11/app-defaults/</tt> (use of a
          localized subdirectory of <tt>/etc/X11/</tt> as described in
          the <em>X Toolkit Intrinsics - C Language Interface</em>
          manual is also permitted).  They must be registered as
          <em>conffile</em>s or handled as configuration files.  For
          programs that are not linked against the X Toolkit (Xt)
          library, customization of programs' X resources may also be
          supported with the provision of a file with the same name as
          that of the package placed in the
          <tt>/etc/X11/Xresources/</tt> directory, which must
          registered as a <em>conffile</em> or handled as a
          configuration file.  <em>Important:</em> packages that
          install files into the <tt>/etc/X11/Xresources/</tt>
          directory <em>must</em> declare a conflict with <tt>xbase
          (&lt;&lt; 3.3.2.3a-2)</tt>; if this is not done it is
          possible for the installing package to destroy a
          previously-existing <tt>/etc/X11/Xresources</tt> file which
          had been customized by the system administrator.
        </p>

        <p>
          <em>Packages using the X Window System should abide by the
            FHS standard whenever possible</em>; they should install
            binaries, libraries, manual pages, and other files in
            FHS-mandated locations wherever possible.  This means that
            files must not be installed into <tt>/usr/X11R6/bin/</tt>,
            <tt>/usr/X11R6/lib/</tt>, or <tt>/usr/X11R6/man/</tt>
            unless this is necessary for the package to operate
            properly.  Configuration files for window managers and
            display managers should be placed in a subdirectory of
            <tt>/etc/X11/</tt> corresponding to the package name due
            to these programs' tight integration with the mechanisms
            of the X Window System.  Application-level programs should
            use the <tt>/etc/</tt> directory unless otherwise mandated
            by policy.  The installation of files into subdirectories
            of <tt>/usr/X11R6/include/X11/</tt> and
            <tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
            package maintainers should determine if subdirectories of
            <tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
            instead (symlinks from the X11R6 directories to
            FHS-compliant locations is encouraged if the program is
            not easily configured to look elsewhere for its files).
            Packages must not provide or install files into the
            directories <tt>/usr/bin/X11/</tt>,
            <tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>.
            Files within a package should, however, make reference to
            these directories, rather than their X11R6-named
            counterparts <tt>/usr/X11R6/bin/</tt>,
            <tt>/usr/X11R6/include/X11/</tt>, and
            <tt>/usr/X11R6/lib/X11/</tt>, if the resources being
            referred to have not been moved to FHS-compliant
            locations.
        </p>

        <p>
          <em>Programs that require the non-DFSG-compliant OSF/Motif
            library</em> should be compiled against and tested with
          LessTif (a free re-implementation of Motif) instead.  If the
          maintainer judges that the program or programs do not work
          sufficiently well with LessTif to be distributed and
          supported, but do so when compiled against Motif, then two
          versions of the package should be created; one linked
          statically against Motif and with <tt>-smotif</tt> appended
          to the package name, and one linked dynamically against
          Motif and with <tt>-dmotif</tt> appended to the package
          name.  Both Motif-linked versions are dependent upon
          non-DFSG-compliant software and thus cannot be uploaded to
          the main distribution; if the software is itself
          DFSG-compliant it may be uploaded to the contrib
          distribution.  While known existing versions of OSF/Motif
          permit unlimited redistribution of binaries linked against
          the library (whether statically or dynamically), it is the
          package maintainer's responsibility to determine whether
          this is permitted by the license of the copy of OSF/Motif in
          his or her possession.
        </p>
      </sect>

      <sect>
        <heading>Perl programs and modules</heading>
        <p>
          Perl programs and modules should follow the current Perl             
          policy as defined in the file found on                               
          <ftpsite>ftp.debian.org</ftpsite> in                                 
          <ftppath>/debian/doc/package-developer/perl-policy.txt.gz</ftppath>  
          or your local mirror.  In addition, it is included in the            
          <tt>debian-policy</tt> package.                                
        </p>
      </sect>

      <sect>
        <heading>Emacs lisp programs</heading>

        <p>
          Please refer to the `Debian Emacs Policy' (documented in
          <tt>debian-emacs-policy.gz</tt> of the
          <prgn>emacsen-common</prgn> package) for details of how to
          package emacs lisp programs.</p></sect>


      <sect>
        <heading>Games</heading>

        <p>
          The permissions on /var/games are 755
          <tt>root.root</tt>.</p>

        <p>
          Each game decides on its own security policy.</p>

        <p>
          Games which require protected, privileged access to
          high-score files, savegames, etc., may be made
          set-<em>group</em>-id (mode 2755) and owned by
          <tt>root.games</tt>, and use files and directories with
          appropriate permissions (770 <tt>root.games</tt>, for
          example).  They must not be made
          set-<em>user</em>-id, as this causes security problems. (If
          an attacker can subvert any set-user-id game they can
          overwrite the executable of any other, causing other players
          of these games to run a Trojan horse program.  With a
          set-group-id game the attacker only gets access to less
          important game data, and if they can get at the other
          players' accounts at all it will take considerably more
          effort.)</p>

        <p>
          Some packages, for example some fortune cookie programs, are
          configured by the upstream authors to install with their
          data files or other static information made unreadable so
          that they can only be accessed through set-id programs
          provided.  You should not do this in a Debian package: anyone can
          download the <tt>.deb</tt> file and read the data from it,
          so there is no point making the files unreadable.  Not
          making the files unreadable also means that you don't have
          to make so many programs set-id, which reduces the risk of a
          security hole.</p>

        <p>
          As described in the FHS, binaries of games should be
          installed in the directory <tt>/usr/games</tt>. This also
          applies to games that use the X Window System. Manual pages
          for games (X and non-X games) should be installed in
          <tt>/usr/share/man/man6</tt>.</p>
      </sect>
    </chapt>

    <chapt id="docs"><heading>Documentation</heading>


      <sect>
        <heading>Manual pages</heading>

        <p>
          You should install manual pages in <prgn>nroff</prgn> source
          form, in appropriate places under <tt>/usr/share/man</tt>.  You
          should only use sections 1 to 9 (see the FHS for more
          details).  You must not install a preformatted `cat
          page'.</p>

        <p>
          Each program, utility, and function should have an
          associated manpage included in the same package. It is
          suggested that all configuration files also have a manual
          page included as well.
        </p>

        <p>
          If no manual page is available for a particular program,
          utility, function or configuration file and this is reported as a bug on
          debian-bugs, a symbolic link from the requested manual page
          to the <manref name="undocumented" section="7"> manual page
          may be provided.  This symbolic link can be created from
          <tt>debian/rules</tt> like this:
          <example compact="compact">
ln -s ../man7/undocumented.7.gz \
debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz
          </example>
          This manpage claims that the lack of a manpage has been
          reported as a bug, so you may only do this if it really has
          (you can report it yourself, if you like).  Do not close the
          bug report until a proper manpage is available.</p>

        <p>
          You may forward a complaint about a missing manpage to the
          upstream authors, and mark the bug as forwarded in the
          Debian bug tracking system.  Even though the GNU Project do
          not in general consider the lack of a manpage to be a bug,
          we do; if they tell you that they don't consider it a bug
          you should leave the bug in our bug tracking system open
          anyway.</p>

        <p>
          Manual pages should be installed compressed using <tt>gzip
            -9</tt>.</p>

        <p>
          If one manpage needs to be accessible via several names it
          is better to use a symbolic link than the <tt>.so</tt>
          feature, but there is no need to fiddle with the relevant
          parts of the upstream source to change from <tt>.so</tt> to
          symlinks: don't do it unless it's easy.  You should not create hard
          links in the manual page directories, nor put
          absolute filenames in <tt>.so</tt> directives.  The filename
          in a <tt>.so</tt> in a manpage should be relative to the
          base of the manpage tree (usually
          <tt>/usr/share/man</tt>).</p></sect>


      <sect>
        <heading>Info documents</heading>

        <p>
          Info documents should be installed in <tt>/usr/share/info</tt>.
          They should be compressed with <tt>gzip -9</tt>.</p>

        <p>
          Your package should call <prgn>install-info</prgn> to update the Info
          <tt>dir</tt>
          file, in its post-installation script:
          <example compact="compact">
install-info --quiet --section Development Development \
/usr/share/info/foobar.info
          </example></p>

        <p>
          It is a good idea to specify a section for the location of
          your program; this is done with the <tt>--section</tt>
          switch.  To determine which section to use, you should look
          at <tt>/usr/share/info/dir</tt> on your system and choose the most
          relevant (or create a new section if none of the current
          sections are relevant).  Note that the <tt>--section</tt>
          flag takes two arguments; the first is a regular expression
          to match (case-insensitively) against an existing section,
          the second is used when creating a new one.</p>

        <p>
          You should remove the entries in the pre-removal script:
          <example compact="compact">
install-info --quiet --remove /usr/share/info/foobar.info
          </example></p>

        <p>
          If <prgn>install-info</prgn> cannot find a description entry
          in the Info file you must supply one.  See <manref
                                                             name="install-info" section="8"> for details.</p>
      </sect>

      <sect>
        <heading>Additional documentation</heading>

        <p>
          Any additional documentation that comes with the package may
          be installed at the discretion of the package maintainer.
          Text documentation should be installed in a directory
          <tt>/usr/share/doc/<var>package</var></tt>, where
          <var>package</var> is the name of the package, and
          compressed with <tt>gzip -9</tt> unless it is small.</p>

        <p>
          If a package comes with large amounts of documentation which
          many users of the package will not require you should create
          a separate binary package to contain it, so that it does not
          take up disk space on the machines of users who do not need
          or want it installed.</p>

        <p>
          It is often a good idea to put text information files
          (<tt>README</tt>s, changelogs, and so forth) that come with
          the source package in <tt>/usr/share/doc/<var>package</var></tt>
          in the binary package.  However, you don't need to install
          the instructions for building and installing the package, of
          course!</p>

        <p>
          Files in <tt>/usr/share/doc</tt> should not be referenced by
          any program, and the system administrator should be able to
          delete them without causing any programs to break. Any files
          that are referenced by programs but are also useful as
          standalone documentation should be installed under
          <tt>/usr/share/<var>package</var>/</tt> and symlinked in
          <tt>/usr/share/doc/<var>package</var>/</tt>.
        </p>

      </sect>

      <sect id="usrdoc">
        <heading>Accessing the documentation</heading>

        <p>
          Former Debian releases placed all additional documentation
          in <tt>/usr/doc/<var>package</var></tt>.  To realize a
          smooth migration to
          <tt>/usr/share/doc/<var>package</var></tt>, each package
          must maintain a symlink <tt>/usr/doc/<var>package</var></tt>
          that points to the new location of its documentation in
          <tt>/usr/share/doc/<var>package</var></tt><footnote>These
              symlinks will be removed in the future, but they have to be
              there for compatibility reasons until all packages have
              moved and the policy is changed accordingly.</footnote>.
          The symlink must be created when the package is installed;
          it cannot be contained in the package itself due to problems
          with <prgn>dpkg</prgn>. One reasonable way to accomplish
          this is to put the following in the package's
          <prgn>postinst</prgn>:
          <example compact="compact">
if [ "$1" = "configure" ]; then
  if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \
       -a -d /usr/share/doc/#PACKAGE# ]; then
    ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE#
  fi
fi
          </example>
          And the following in the package's <prgn>prerm</prgn>:
          <example compact="compact">
if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
     -a -L /usr/doc/#PACKAGE# ]; then
  rm -f /usr/doc/#PACKAGE#
fi
          </example>
        </p>
      </sect>

      <sect>
        <heading>Preferred documentation formats</heading>

        <p>
          The unification of Debian documentation is being carried out
          via HTML.</p>

        <p>
          If your package comes with extensive documentation in a
          mark up format that can be converted to various other formats
          you should if possible ship HTML versions in a binary
          package, in the directory
          <tt>/usr/share/doc/<var>appropriate package</var></tt> or its
          subdirectories.
          <footnote>
            <p>The rationale: The important thing here is that HTML
              docs should be available in <em>some</em> package, not
              necessarily in the main binary package, though. </p>
          </footnote>
        </p>

        <p>
          Other formats such as PostScript may be provided at your
          option.</p>
      </sect>

      <sect id="copyrightfile">
        <heading>Copyright information</heading>

        <p>
          Every package must be accompanied by a verbatim copy of its
          copyright and distribution license in the file
          /usr/share/doc/<var>package</var>/copyright. This file must
          neither be compressed nor be a symbolic link.</p>

        <p>
          In addition, the copyright file must say where the upstream
          sources (if any) were obtained, and should explain briefly what
          modifications were made in the Debian version of the package
          compared to the upstream one.  It should name the original
          authors of the package and the Debian maintainer(s) who were
          involved with its creation.</p>

        <p>
          A copy of the file which will be installed in
          <tt>/usr/share/doc/<var>package</var>/copyright</tt> should be
          in <tt>debian/copyright</tt>.</p>


        <p>
          /usr/share/doc/<var>package</var> may be a symbolic link to a
          directory in /usr/share/doc only if two packages both come from
          the same source and the first package has a "Depends"
          relationship on the second.  These rules are important
          because copyrights must be extractable by mechanical
          means.</p>

        <p>
          Packages distributed under the UCB BSD license, the Artistic
          license, the GNU GPL, and the GNU LGPL should refer to the
          files /usr/share/common-licenses/BSD,
          /usr/share/common-licenses/Artistic,
          /usr/share/common-licenses/GPL, and
          /usr/share/common-licenses/LGPL.
          <footnote>
            <p>
              Why "licenses" and not "copyright"? Because
              <tt>/usr/doc/copyright</tt> used to contain all the
              copyright files, plus the four common licenses GPL,
              LGPL, Artistic and BSD. Now individual copyright files
              for packages are no longer in a common directory. Once
              <tt>/usr/doc/copyright</tt> is almost empty it makes
              sense to rename "copyright" to "licenses"
            </p>
            <p>
              Why "common-licenses" and not "licenses"? Because if I
              put just "licenses" I'm sure I will receive a bug report
              saying "license foo is not included in the licenses
              directory. They are not all the licenses, just a few
              common ones. I could use /usr/share/doc/common-licenses
              but I think this is too long, and, after all, the GPL
              does not "document" anything, it is merely a license.
            </p>
          </footnote>
        </p>

        <p>
          You should not use the copyright file as a general <tt>README</tt>
          file.  If your package has such a file it should be
          installed in <tt>/usr/share/doc/<var>package</var>/README</tt> or
          <tt>README.Debian</tt> or some other appropriate place.</p>
      </sect>

      <sect>
        <heading>Examples</heading>

        <p>
          Any examples (configurations, source files, whatever),
          should be installed in a directory
          <tt>/usr/share/doc/<var>package</var>/examples</tt>.  These
          files should not be referenced by any program: they're there
          for the benefit of the system administrator and users, as
          documentation only. Architecture-specific example files
          should be installed in a directory
          <tt>/usr/lib/<var>package</var>/examples</tt>, and files in
          <tt>/usr/share/doc/<var>package</var>/examples</tt> symlink
          to files in it. Or the latter directory may be a symlink to
          the former.</p>
      </sect>

      <sect id="instchangelog">
        <heading>Changelog files</heading>

        <p>
          Packages that are not Debian-native must contain a copy of
          <tt>debian/changelog</tt> file from the Debian source tree
          in <tt>/usr/share/doc/<var>package</var></tt> as
          <tt>changelog.Debian.gz</tt>. If an upstream changelog is
          available, it should be accessible as
          <tt>/usr/share/doc/<var>package</var>/changelog.gz</tt> in
          plain text. If the upstream changelog is distributed in
          HTML, it should be made available in that form as
          <tt>/usr/share/doc/<var>package</var>/changelog.html.gz</tt>
          and the <tt>changelog.gz</tt> should be generated using, eg,
          <tt>lynx -dump -nolist</tt>. If the upstream changelog files
          do not already conform to this naming convention, then this
          may be achieved either by renaming the files, or adding a
          symbolic link, at the maintainer's discretion.
          <footnote>
            <p>
              Rationale: People should not have to look into two
              places for upstream changelogs merely because they are
              in HTML format.
            </p>
          </footnote>
        </p>


        <p>
          All these files should be installed compressed using <tt>gzip -9</tt>,
          as they will become large with time even if they start out
          small.
        </p>

        <p>
          If the package has only one changelog which is used both as
          the Debian changelog and the upstream one because there is
          no separate upstream maintainer then that changelog should
          usually be installed as
          <tt>/usr/share/doc/<var>package</var>/changelog.gz</tt>; if
          there is a separate upstream maintainer, but no upstream
          changelog, then the Debian changelog should still be called
          <tt>changelog.Debian.gz</tt>.</p>
      </sect>
    </chapt>
  </book>
</debiandoc>