Gecko [ fernandoquevedodop.com ]

Name	Size	Permission
_images	[ DIR ]	drwxr-xr-x
_sources	[ DIR ]	drwxr-xr-x
_static	[ DIR ]	drwxr-xr-x
ap-flowcharts.html	7.02 KB	-rw-r--r--
ap-license.html	4.8 KB	-rw-r--r--
ap-pkg-alternatives.html	6.79 KB	-rw-r--r--
ap-pkg-binarypkg.html	17.44 KB	-rw-r--r--
ap-pkg-conffiles.html	12.14 KB	-rw-r--r--
ap-pkg-controlfields.html	12.4 KB	-rw-r--r--
ap-pkg-diversions.html	11.4 KB	-rw-r--r--
ap-pkg-scope.html	7.81 KB	-rw-r--r--
ap-pkg-sourcepkg.html	33.32 KB	-rw-r--r--
ap-process.html	18.49 KB	-rw-r--r--
ch-archive.html	28.57 KB	-rw-r--r--
ch-binary.html	38.01 KB	-rw-r--r--
ch-controlfields.html	107.38 KB	-rw-r--r--
ch-customized-programs.html	53.09 KB	-rw-r--r--
ch-docs.html	33.97 KB	-rw-r--r--
ch-files.html	69.51 KB	-rw-r--r--
ch-maintainerscripts.html	40.34 KB	-rw-r--r--
ch-opersys.html	84.18 KB	-rw-r--r--
ch-relationships.html	67.18 KB	-rw-r--r--
ch-scope.html	18.54 KB	-rw-r--r--
ch-sharedlibs.html	88.6 KB	-rw-r--r--
ch-source.html	79.4 KB	-rw-r--r--
genindex.html	3.48 KB	-rw-r--r--
index.html	59.51 KB	-rw-r--r--
objects.inv	4.75 KB	-rw-r--r--
search.html	2.99 KB	-rw-r--r--
searchindex.js	58.77 KB	-rw-r--r--
upgrading-checklist.html	121.38 KB	-rw-r--r--

Code Editor : ch-binary.html

<!DOCTYPE html>

<title>3. Binary packages &#8212; Debian Policy Manual v4.6.0.1</title>
    <link rel="stylesheet" type="text/css" href="_static/pygments.css" />
    <link rel="stylesheet" type="text/css" href="_static/nature.css" />
    <script data-url_root="./" id="documentation_options" src="_static/documentation_options.js"></script>
    <script src="_static/jquery.js"></script>
    <script src="_static/underscore.js"></script>
    <script src="_static/doctools.js"></script>
    <link rel="index" title="Index" href="genindex.html" />
    <link rel="search" title="Search" href="search.html" />
    <link rel="next" title="4. Source packages" href="ch-source.html" />
    <link rel="prev" title="2. The Debian Archive" href="ch-archive.html" /> 
  </head><body>
    <div class="related" role="navigation" aria-label="related navigation">
      <h3>Navigation</h3>
      <ul>
        <li class="right" style="margin-right: 10px">
          <a href="genindex.html" title="General Index"
             accesskey="I">index</a></li>
        <li class="right" >
          <a href="ch-source.html" title="4. Source packages"
             accesskey="N">next</a> |</li>
        <li class="right" >
          <a href="ch-archive.html" title="2. The Debian Archive"
             accesskey="P">previous</a> |</li>
        <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> &#187;</li>
        <li class="nav-item nav-item-this"><a href=""><span class="section-number">3. </span>Binary packages</a></li> 
      </ul>
    </div>

<div class="document">
      <div class="documentwrapper">
        <div class="bodywrapper">
          <div class="body" role="main">
            
  <section id="binary-packages">
<h1><span class="section-number">3. </span>Binary packages<a class="headerlink" href="#binary-packages" title="Permalink to this headline">¶</a></h1>
<p>The Debian distribution is based on the Debian package management
system, called <code class="docutils literal notranslate"><span class="pre">dpkg</span></code>. Thus, all packages in the Debian distribution
must be provided in the <code class="docutils literal notranslate"><span class="pre">.deb</span></code> file format.</p>
<p>A <code class="docutils literal notranslate"><span class="pre">.deb</span></code> package contains two sets of files: a set of files to install
on the system when the package is installed, and a set of files that
provide additional metadata about the package or which are executed when
the package is installed or removed. This second set of files is called
<em>control information files</em>. Among those files are the package maintainer
scripts and <code class="docutils literal notranslate"><span class="pre">control</span></code>, the <a class="reference internal" href="ch-controlfields.html#s-binarycontrolfiles"><span class="std std-ref">binary package control file</span></a> that contains the control fields for the
package. Other control information files include <a class="reference internal" href="ch-sharedlibs.html#s-sharedlibs-symbols"><span class="std std-ref">symbols</span></a> or <a class="reference internal" href="ch-sharedlibs.html#s-sharedlibs-shlibdeps"><span class="std std-ref">shlibs</span></a> used to
store shared library dependency information and the <code class="docutils literal notranslate"><span class="pre">conffiles</span></code> file
that lists the package’s configuration files (described in
<a class="reference internal" href="ch-files.html#s-config-files"><span class="std std-ref">Configuration files</span></a>).</p>
<p>There is unfortunately a collision of terminology here between control
information files and files in the Debian control file format.
Throughout this document, a <em>control file</em> refers to a file in the
Debian control file format. These files are documented in
<a class="reference internal" href="ch-controlfields.html"><span class="doc">Control files and their fields</span></a>. Only files
referred to specifically as <em>control information files</em> are the files
included in the control information file member of the <code class="docutils literal notranslate"><span class="pre">.deb</span></code> file
format used by binary packages. Most control information files are not
in the Debian control file format.</p>
<section id="the-package-name">
<span id="s3-1"></span><h2><span class="section-number">3.1. </span>The package name<a class="headerlink" href="#the-package-name" title="Permalink to this headline">¶</a></h2>
<p>Every package must have a name that’s unique within the Debian archive.</p>
<p>The package name is included in the control field <code class="docutils literal notranslate"><span class="pre">Package</span></code>, the
format of which is described in <a class="reference internal" href="ch-controlfields.html#s-f-package"><span class="std std-ref">Package</span></a>. The
package name is also included as a part of the file name of the <code class="docutils literal notranslate"><span class="pre">.deb</span></code>
file.</p>
<section id="packages-with-potentially-offensive-content">
<span id="s3-1-1"></span><h3><span class="section-number">3.1.1. </span>Packages with potentially offensive content<a class="headerlink" href="#packages-with-potentially-offensive-content" title="Permalink to this headline">¶</a></h3>
<p>As a maintainer you should make a judgement about whether the contents
of a package is appropriate to include, whether it needs any kind of
content warning, and whether some parts should be split out into a
separate package (so that users who want to avoid certain parts can do
so).  In making these decisions you should take into account the
project’s views as expressed in our Diversity Statement.</p>
<p>If you split out (potentially) offensive or disturbing material into a
separate package, you should usually mark this in the package name by
adding <code class="docutils literal notranslate"><span class="pre">-offensive</span></code>.  For example, <code class="docutils literal notranslate"><span class="pre">cowsay</span></code> vs
<code class="docutils literal notranslate"><span class="pre">cowsay-offensive</span></code>.  In this situation the <code class="docutils literal notranslate"><span class="pre">-offensive</span></code> package
can be Suggested by the core package(s), but should not be Recommended
or Depended on.</p>
</section>
</section>
<section id="the-version-of-a-package">
<span id="s-versions"></span><h2><span class="section-number">3.2. </span>The version of a package<a class="headerlink" href="#the-version-of-a-package" title="Permalink to this headline">¶</a></h2>
<p>Every package has a version number recorded in its <code class="docutils literal notranslate"><span class="pre">Version</span></code> control
file field, described in <a class="reference internal" href="ch-controlfields.html#s-f-version"><span class="std std-ref">Version</span></a>.</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>If an upstream package has problematic version numbers they should be
converted to a sane form for use in the <code class="docutils literal notranslate"><span class="pre">Version</span></code> field.</p>
<section id="version-numbers-based-on-dates">
<span id="s3-2-1"></span><h3><span class="section-number">3.2.1. </span>Version numbers based on dates<a class="headerlink" href="#version-numbers-based-on-dates" title="Permalink to this headline">¶</a></h3>
<p>In general, Debian packages should use the same version numbers as the
upstream sources. However, upstream version numbers based on some date
formats (sometimes used for development or “snapshot” releases) will not
be ordered correctly by the package management software. For example,
<code class="docutils literal notranslate"><span class="pre">dpkg</span></code> will consider “96May01” to be greater than “96Dec24”.</p>
<p>To prevent having to use epochs for every new upstream version, the
date-based portion of any upstream version number should be given in a
way that sorts correctly: four-digit year first, followed by a two-digit
numeric month, followed by a two-digit numeric date, possibly with
punctuation between the components.</p>
<p>Native Debian packages (i.e., packages which have been written
especially for Debian) whose version numbers include dates should also
follow these rules. If punctuation is desired between the date
components, remember that hyphen (<code class="docutils literal notranslate"><span class="pre">-</span></code>) cannot be used in native
version numbers. Period (<code class="docutils literal notranslate"><span class="pre">.</span></code>) is normally a good choice.</p>
</section>
<section id="uniqueness-of-version-numbers">
<span id="s3-2-2"></span><h3><span class="section-number">3.2.2. </span>Uniqueness of version numbers<a class="headerlink" href="#uniqueness-of-version-numbers" title="Permalink to this headline">¶</a></h3>
<p>The part of the version number after the epoch must not be reused for
a version of the package with different contents once the package has
been accepted into the archive, even if the version of the package
previously using that part of the version number is no longer present
in any archive suites.</p>
<p>This uniqueness requirement applies to the version numbers of source
packages and of binary packages, even if the source package producing
a given binary package changes.  Thus the version numbers which a
binary package must not reuse includes the version numbers of any
versions of the binary package ever accepted into the archive, under
any source package.</p>
<p>Additionally, for non-native packages, the upstream version must not
be reused for different upstream source code, so that for each source
package name and upstream version number there exists exactly one
original source archive contents (see <a class="reference internal" href="ch-controlfields.html#s-f-files"><span class="std std-ref">Files</span></a>).</p>
<p>The reason for these restrictions is as follows.  Epochs are not
included in the names of the files that compose source packages, or in
the filenames of binary packages, so reusing a version number, even if
the epoch differs, results in identically named files with different
contents.  This can cause various problems.</p>
<p>If you find yourself wanting to reuse the part of a version number
after the epoch, you can just increment the Debian revision, which
doesn’t need to start at 1 or be consecutive.</p>
</section>
</section>
<section id="the-maintainer-of-a-package">
<span id="s-maintainer"></span><h2><span class="section-number">3.3. </span>The maintainer of a package<a class="headerlink" href="#the-maintainer-of-a-package" title="Permalink to this headline">¶</a></h2>
<p>Every package must have a maintainer, except for orphaned packages as
described below. 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 maintaining the Debian packaging files,
evaluating and responding appropriately to reported bugs, uploading new
versions of the package (either directly or through a sponsor), ensuring
that the package is placed in the appropriate archive area and included
in Debian releases as appropriate for the stability and utility of the
package, and requesting removal of the package from the Debian
distribution if it is no longer useful or maintainable.</p>
<p>The maintainer must be specified in the <code class="docutils literal notranslate"><span class="pre">Maintainer</span></code> control field
with their correct name and a working email address. The email address
given in the <code class="docutils literal notranslate"><span class="pre">Maintainer</span></code> control field must accept mail from those
role accounts in Debian used to send automated mails regarding the
package. This includes non-spam mail from the bug-tracking system, all
mail from the Debian archive maintenance software, and other role
accounts or automated processes that are commonly agreed on by the
project.  <a class="footnote-reference brackets" href="#id6" id="id1">1</a> If one person or team maintains several packages, they
should use the same form of their name and email address in the
<code class="docutils literal notranslate"><span class="pre">Maintainer</span></code> fields of those packages.</p>
<p>The format of the <code class="docutils literal notranslate"><span class="pre">Maintainer</span></code> control field is described in
<a class="reference internal" href="ch-controlfields.html#s-f-maintainer"><span class="std std-ref">Maintainer</span></a>.</p>
<p>If the maintainer of the package is a team of people with a shared email
address, the <code class="docutils literal notranslate"><span class="pre">Uploaders</span></code> control field must be present and must
contain at least one human with their personal email address. See
<a class="reference internal" href="ch-controlfields.html#s-f-uploaders"><span class="std std-ref">Uploaders</span></a> for the syntax of that field.</p>
<p>An orphaned package is one with no current maintainer. Orphaned packages
should have their <code class="docutils literal notranslate"><span class="pre">Maintainer</span></code> control field set to <code class="docutils literal notranslate"><span class="pre">Debian</span> <span class="pre">QA</span> <span class="pre">Group</span> <span class="pre">&lt;packages&#64;qa.debian.org&gt;</span></code>. These packages are considered
maintained by the Debian project as a whole until someone else
volunteers to take over maintenance.  <a class="footnote-reference brackets" href="#id7" id="id2">2</a></p>
</section>
<section id="the-description-of-a-package">
<span id="s-descriptions"></span><h2><span class="section-number">3.4. </span>The description of a package<a class="headerlink" href="#the-description-of-a-package" title="Permalink to this headline">¶</a></h2>
<p>Every Debian package must have a <code class="docutils literal notranslate"><span class="pre">Description</span></code> control field which
contains a synopsis and extended description of the package. Technical
information about the format of the <code class="docutils literal notranslate"><span class="pre">Description</span></code> field is in
<a class="reference internal" href="ch-controlfields.html#s-f-description"><span class="std std-ref">Description</span></a>.</p>
<p>The description should describe the package (the program) to a user
(system administrator) who has never met it before so that they have
enough information to decide whether they want to install it. This
description should not just be copied verbatim from the program’s
documentation.</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>The description 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>
<p>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>
<section id="the-single-line-synopsis">
<span id="s-synopsis"></span><h3><span class="section-number">3.4.1. </span>The single line synopsis<a class="headerlink" href="#the-single-line-synopsis" title="Permalink to this headline">¶</a></h3>
<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>
</section>
<section id="the-extended-description">
<span id="s-extendeddesc"></span><h3><span class="section-number">3.4.2. </span>The extended description<a class="headerlink" href="#the-extended-description" title="Permalink to this headline">¶</a></h3>
<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.  <a class="footnote-reference brackets" href="#id8" id="id3">3</a></p>
</section>
</section>
<section id="dependencies">
<span id="s-dependencies"></span><h2><span class="section-number">3.5. </span>Dependencies<a class="headerlink" href="#dependencies" title="Permalink to this headline">¶</a></h2>
<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 <code class="docutils literal notranslate"><span class="pre">Essential</span></code> (see below), and should not do
so unless they depend on a particular version of that package.  <a class="footnote-reference brackets" href="#id9" id="id4">4</a></p>
<p>Sometimes, unpacking one package requires that another package be first
unpacked <em>and</em> configured. In this case, the depending package must
specify this dependency in the <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> control field.</p>
<p>You should not specify a <code class="docutils literal notranslate"><span class="pre">Pre-Depends</span></code> entry for a package before this
has been discussed on the <code class="docutils literal notranslate"><span class="pre">debian-devel</span></code> mailing list and a consensus
about doing that has been reached.</p>
<p>The format of the package interrelationship control fields is described
in <a class="reference internal" href="ch-relationships.html"><span class="doc">Declaring relationships between packages</span></a>.</p>
</section>
<section id="virtual-packages">
<span id="s-virtual-pkg"></span><h2><span class="section-number">3.6. </span>Virtual packages<a class="headerlink" href="#virtual-packages" title="Permalink to this headline">¶</a></h2>
<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. (See also <a class="reference internal" href="ch-relationships.html#s-virtual"><span class="std std-ref">Virtual packages - Provides</span></a>)</p>
<p>The latest version of the authoritative list of virtual package names
can be found in the <code class="docutils literal notranslate"><span class="pre">debian-policy</span></code> package. It is also available from
the Debian web mirrors at
<a class="reference external" href="https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml">https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml</a>.</p>
<p>The procedure for updating the list is described in the preface to the
list.</p>
</section>
<section id="base-system">
<span id="s3-7"></span><h2><span class="section-number">3.7. </span>Base system<a class="headerlink" href="#base-system" title="Permalink to this headline">¶</a></h2>
<p>The <code class="docutils literal notranslate"><span class="pre">base</span> <span class="pre">system</span></code> is a minimum subset of the Debian system that is
installed before everything else on a new system. Only very few packages
are allowed to form part of the base system, in order to keep the
required disk usage very small.</p>
<p>The base system consists of all those packages with priority
<code class="docutils literal notranslate"><span class="pre">required</span></code> or <code class="docutils literal notranslate"><span class="pre">important</span></code>. Many of them will be tagged <code class="docutils literal notranslate"><span class="pre">essential</span></code>
(see below).</p>
</section>
<section id="essential-packages">
<span id="s3-8"></span><h2><span class="section-number">3.8. </span>Essential packages<a class="headerlink" href="#essential-packages" title="Permalink to this headline">¶</a></h2>
<p>Essential is defined as the minimal set of functionality that must be
available and usable on the system at all times, even when packages are
in the “Unpacked” state. Packages are tagged <code class="docutils literal notranslate"><span class="pre">essential</span></code> for a system
using the <code class="docutils literal notranslate"><span class="pre">Essential</span></code> control field. The format of the <code class="docutils literal notranslate"><span class="pre">Essential</span></code>
control field is described in <a class="reference internal" href="ch-controlfields.html#s-f-essential"><span class="std std-ref">Essential</span></a>.</p>
<p>Since these packages cannot be easily removed (one has to specify an
extra <em>force option</em> to <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> to do so), this flag must not be used
unless absolutely necessary. A shared library package must not be tagged
<code class="docutils literal notranslate"><span class="pre">essential</span></code>; 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
<code class="docutils literal notranslate"><span class="pre">essential</span></code> package is in an unconfigured state, all <code class="docutils literal notranslate"><span class="pre">essential</span></code>
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>Maintainers should take great care in adding any programs, interfaces,
or functionality to <code class="docutils literal notranslate"><span class="pre">essential</span></code> packages. Packages may assume that
functionality provided by <code class="docutils literal notranslate"><span class="pre">essential</span></code> packages is always available
without declaring explicit dependencies, which means that removing
functionality from the Essential set is very difficult and is almost
never done. Any capability added to an <code class="docutils literal notranslate"><span class="pre">essential</span></code> package therefore
creates an obligation to support that capability as part of the
Essential set in perpetuity.</p>
<p>You must not tag any packages <code class="docutils literal notranslate"><span class="pre">essential</span></code> before this has been
discussed on the <code class="docutils literal notranslate"><span class="pre">debian-devel</span></code> mailing list and a consensus about
doing that has been reached.</p>
</section>
<section id="maintainer-scripts">
<span id="s-maintscripts"></span><h2><span class="section-number">3.9. </span>Maintainer Scripts<a class="headerlink" href="#maintainer-scripts" title="Permalink to this headline">¶</a></h2>
<p>The package installation scripts should avoid producing output which is
unnecessary for the user to see and should rely on <code class="docutils literal notranslate"><span class="pre">dpkg</span></code> to stave off
boredom on the part of a user installing many packages. This means,
amongst other things, not passing the <code class="docutils literal notranslate"><span class="pre">--verbose</span></code> option to
<code class="docutils literal notranslate"><span class="pre">update-alternatives</span></code>.</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 <a class="reference internal" href="ch-files.html#s-scripts"><span class="std std-ref">Scripts</span></a> applies to package
maintainer scripts, too.</p>
<p>You should not use <code class="docutils literal notranslate"><span class="pre">dpkg-divert</span></code> on a file belonging to another
package without consulting the maintainer of that package first. When
adding or removing diversions, package maintainer scripts must provide
the <code class="docutils literal notranslate"><span class="pre">--package</span></code> flag to <code class="docutils literal notranslate"><span class="pre">dpkg-divert</span></code> and must not use <code class="docutils literal notranslate"><span class="pre">--local</span></code>.</p>
<p>All packages which supply an instance of a common command name (or, in
general, filename) should generally use <code class="docutils literal notranslate"><span class="pre">update-alternatives</span></code> so that
they can be installed together. If <code class="docutils literal notranslate"><span class="pre">update-alternatives</span></code> is not used,
then each package must use <code class="docutils literal notranslate"><span class="pre">Conflicts</span></code> to ensure that other packages
are removed. (In this case, it may be appropriate to specify a conflict
against earlier versions of something that previously did not use
<code class="docutils literal notranslate"><span class="pre">update-alternatives</span></code>; this is an exception to the usual rule that
versioned conflicts should be avoided.)</p>
<section id="prompting-in-maintainer-scripts">
<span id="s-maintscriptprompt"></span><h3><span class="section-number">3.9.1. </span>Prompting in maintainer scripts<a class="headerlink" href="#prompting-in-maintainer-scripts" title="Permalink to this headline">¶</a></h3>
<p>Package maintainer scripts may prompt the user if necessary. Prompting
must be done by communicating through a program, such as <code class="docutils literal notranslate"><span class="pre">debconf</span></code>,
which conforms to the Debian Configuration Management Specification,
version 2 or higher.</p>
<p>Packages which are essential, or which are dependencies of essential
packages, may fall back on another prompting method if no such interface
is available when they are executed.</p>
<p>The Debian Configuration Management Specification is included in the
<code class="docutils literal notranslate"><span class="pre">debconf_specification</span></code> files in the debian-policy package. It is also
available from the Debian web mirrors at
<a class="reference external" href="https://www.debian.org/doc/packaging-manuals/debconf_specification.html">https://www.debian.org/doc/packaging-manuals/debconf_specification.html</a>.</p>
<p>Packages which use the Debian Configuration Management Specification may
contain the additional control information files <code class="docutils literal notranslate"><span class="pre">config</span></code> and
<code class="docutils literal notranslate"><span class="pre">templates</span></code>. <code class="docutils literal notranslate"><span class="pre">config</span></code> is an additional maintainer script used for
package configuration, and <code class="docutils literal notranslate"><span class="pre">templates</span></code> contains templates used for
user prompting. The <code class="docutils literal notranslate"><span class="pre">config</span></code> script might be run before the
<code class="docutils literal notranslate"><span class="pre">preinst</span></code> script and before the package is unpacked or any of its
dependencies or pre-dependencies are satisfied. Therefore it must work
using only the tools present in <em>essential</em> packages.  <a class="footnote-reference brackets" href="#id10" id="id5">5</a></p>
<p>Packages which use the Debian Configuration Management Specification
must allow for translation of their user-visible messages by using a
gettext-based system such as the one provided by the po-debconf package.</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 <code class="docutils literal notranslate"><span class="pre">/etc/papersize</span></code> and
<code class="docutils literal notranslate"><span class="pre">/etc/news/server</span></code>), and shared debconf 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 <code class="docutils literal notranslate"><span class="pre">dpkg</span> <span class="pre">--purge</span></code> to remove the package’s
configuration. The answers to configuration questions should be stored
in an appropriate place in <code class="docutils literal notranslate"><span class="pre">/etc</span></code> 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 <code class="docutils literal notranslate"><span class="pre">config</span></code> or
<code class="docutils literal notranslate"><span class="pre">postinst</span></code> script and prompt the user to hit return to acknowledge the
message. Copyright messages do not count as vitally important (they
belong in <code class="docutils literal notranslate"><span class="pre">/usr/share/doc/PACKAGE/copyright</span></code>); 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
<code class="docutils literal notranslate"><span class="pre">config</span></code> or <code class="docutils literal notranslate"><span class="pre">postinst</span></code> script. If it is done in the <code class="docutils literal notranslate"><span class="pre">postinst</span></code>, it
should be protected with a conditional so that unnecessary prompting
doesn’t happen if a package’s installation fails and the <code class="docutils literal notranslate"><span class="pre">postinst</span></code> is
called with <code class="docutils literal notranslate"><span class="pre">abort-upgrade</span></code>, <code class="docutils literal notranslate"><span class="pre">abort-remove</span></code> or
<code class="docutils literal notranslate"><span class="pre">abort-deconfigure</span></code>.</p>
<dl class="footnote brackets">
<dt class="label" id="id6"><span class="brackets"><a class="fn-backref" href="#id1">1</a></span></dt>
<dd><p>A sample implementation of such a whitelist written for the Mailman
mailing list management software is used for mailing lists hosted by
<a class="reference external" href="https://alioth-lists.debian.net/">https://alioth-lists.debian.net/</a>.</p>
</dd>
<dt class="label" id="id7"><span class="brackets"><a class="fn-backref" href="#id2">2</a></span></dt>
<dd><p>The detailed procedure for gracefully orphaning a package can be
found in the Debian Developer’s Reference (see
<a class="reference internal" href="ch-scope.html#s-related"><span class="std std-ref">Related documents</span></a>).</p>
</dd>
<dt class="label" id="id8"><span class="brackets"><a class="fn-backref" href="#id3">3</a></span></dt>
<dd><p>The blurb that comes with a program in its announcements and/or
<code class="docutils literal notranslate"><span class="pre">README</span></code> 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>
</dd>
<dt class="label" id="id9"><span class="brackets"><a class="fn-backref" href="#id4">4</a></span></dt>
<dd><p>Essential is needed in part to avoid unresolvable dependency loops on
upgrade. If packages add unnecessary dependencies on packages in this
set, the chances that there <strong>will</strong> be an unresolvable dependency
loop caused by forcing these Essential packages to be configured
first before they need to be is greatly increased. It also increases
the chances that frontends will be unable to <strong>calculate</strong> an upgrade
path, even if one exists.</p>
<p>Also, functionality is rarely ever removed from the Essential set,
but <em>packages</em> have been removed from the Essential set when the
functionality moved to a different package. So depending on these
packages <em>just in case</em> they stop being essential does way more harm
than good.</p>
</dd>
<dt class="label" id="id10"><span class="brackets"><a class="fn-backref" href="#id5">5</a></span></dt>
<dd><p>Debconf 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>
</dd>
</dl>
</section>
</section>
</section>

<div class="clearer"></div>
          </div>
        </div>
      </div>
      <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
        <div class="sphinxsidebarwrapper">
  <h3><a href="index.html">Table of Contents</a></h3>
  <ul>
<li><a class="reference internal" href="#">3. Binary packages</a><ul>
<li><a class="reference internal" href="#the-package-name">3.1. The package name</a><ul>
<li><a class="reference internal" href="#packages-with-potentially-offensive-content">3.1.1. Packages with potentially offensive content</a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-version-of-a-package">3.2. The version of a package</a><ul>
<li><a class="reference internal" href="#version-numbers-based-on-dates">3.2.1. Version numbers based on dates</a></li>
<li><a class="reference internal" href="#uniqueness-of-version-numbers">3.2.2. Uniqueness of version numbers</a></li>
</ul>
</li>
<li><a class="reference internal" href="#the-maintainer-of-a-package">3.3. The maintainer of a package</a></li>
<li><a class="reference internal" href="#the-description-of-a-package">3.4. The description of a package</a><ul>
<li><a class="reference internal" href="#the-single-line-synopsis">3.4.1. The single line synopsis</a></li>
<li><a class="reference internal" href="#the-extended-description">3.4.2. The extended description</a></li>
</ul>
</li>
<li><a class="reference internal" href="#dependencies">3.5. Dependencies</a></li>
<li><a class="reference internal" href="#virtual-packages">3.6. Virtual packages</a></li>
<li><a class="reference internal" href="#base-system">3.7. Base system</a></li>
<li><a class="reference internal" href="#essential-packages">3.8. Essential packages</a></li>
<li><a class="reference internal" href="#maintainer-scripts">3.9. Maintainer Scripts</a><ul>
<li><a class="reference internal" href="#prompting-in-maintainer-scripts">3.9.1. Prompting in maintainer scripts</a></li>
</ul>
</li>
</ul>
</li>
</ul>

<h4>Previous topic</h4>
  <p class="topless"><a href="ch-archive.html"
                        title="previous chapter"><span class="section-number">2. </span>The Debian Archive</a></p>
  <h4>Next topic</h4>
  <p class="topless"><a href="ch-source.html"
                        title="next chapter"><span class="section-number">4. </span>Source packages</a></p>
  <div role="note" aria-label="source link">
    <h3>This Page</h3>
    <ul class="this-page-menu">
      <li><a href="_sources/ch-binary.rst.txt"
            rel="nofollow">Show Source</a></li>
    </ul>
   </div>
<div id="searchbox" style="display: none" role="search">
  <h3 id="searchlabel">Quick search</h3>
    <div class="searchformwrapper">
    <form class="search" action="search.html" method="get">
      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
      <input type="submit" value="Go" />
    </form>
    </div>
</div>
<script>$('#searchbox').show(0);</script>
        </div>
      </div>
      <div class="clearer"></div>
    </div>
    <div class="related" role="navigation" aria-label="related navigation">
      <h3>Navigation</h3>
      <ul>
        <li class="right" style="margin-right: 10px">
          <a href="genindex.html" title="General Index"
             >index</a></li>
        <li class="right" >
          <a href="ch-source.html" title="4. Source packages"
             >next</a> |</li>
        <li class="right" >
          <a href="ch-archive.html" title="2. The Debian Archive"
             >previous</a> |</li>
        <li class="nav-item nav-item-0"><a href="index.html">Debian Policy Manual v4.6.0.1</a> &#187;</li>
        <li class="nav-item nav-item-this"><a href=""><span class="section-number">3. </span>Binary packages</a></li> 
      </ul>
    </div>
    <div class="footer" role="contentinfo">
      Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 4.2.0.
    </div>
  </body>
</html>

${this.title}

Code Editor : ch-binary.html