Copyright © 1996,1997,1998 Ian Jackson
and Christian Schwarz.
</copyrightsummary>
+ <p>
+ These are the copyright dates of the original Policy manual.
+ Since then, this manual has been updated by many others. No
+ comprehensive collection of copyright notices for subsequent
+ work exists.
+ </p>
+
<p>
This manual is free software; you may redistribute it and/or
modify it under the terms of the GNU General Public License
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 distribution
- areas or categories based on their licenses and other restrictions.
+ restrictions. Thus, the archive is split into areas<footnote>
+ The Debian archive software uses the term "component" internally
+ and in the Release file format to refer to the division of an
+ archive. The Debian Social Contract simply refers to "areas."
+ This document uses terminology similar to the Social Contract.
+ </footnote> based on their licenses and other restrictions.
</p>
<p>
</p>
<p>
- The <em>main</em> category forms the
- <em>Debian GNU/Linux distribution</em>.
+ The <em>main</em> archive area forms the <em>Debian GNU/Linux
+ distribution</em>.
</p>
<p>
- Packages in the other distribution areas (<tt>contrib</tt>,
+ Packages in the other archive areas (<tt>contrib</tt>,
<tt>non-free</tt>) 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
The Debian Free Software Guidelines (DFSG) form our
definition of "free software". These are:
<taglist>
- <tag>Free Redistribution
+ <tag>1. Free Redistribution
</tag>
<item>
The license of a Debian component may not restrict any
sources. The license may not require a royalty or
other fee for such sale.
</item>
- <tag>Source Code
+ <tag>2. Source Code
</tag>
<item>
The program must include source code, and must allow
distribution in source code as well as compiled form.
</item>
- <tag>Derived Works
+ <tag>3. Derived Works
</tag>
<item>
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.
</item>
- <tag>Integrity of The Author's Source Code
+ <tag>4. Integrity of The Author's Source Code
</tag>
<item>
The license may restrict source-code from being
Project encourages all authors to not restrict any
files, source or binary, from being modified.)
</item>
- <tag>No Discrimination Against Persons or Groups
+ <tag>5. No Discrimination Against Persons or Groups
</tag>
<item>
The license must not discriminate against any person
or group of persons.
</item>
- <tag>No Discrimination Against Fields of Endeavor
+ <tag>6. No Discrimination Against Fields of Endeavor
</tag>
<item>
The license must not restrict anyone from making use
used in a business, or from being used for genetic
research.
</item>
- <tag>Distribution of License
+ <tag>7. Distribution of License
</tag>
<item>
The rights attached to the program must apply to all
for execution of an additional license by those
parties.
</item>
- <tag>License Must Not Be Specific to Debian
+ <tag>8. License Must Not Be Specific to Debian
</tag>
<item>
The rights attached to the program must not depend on
rights as those that are granted in conjunction with
the Debian system.
</item>
- <tag>License Must Not Contaminate Other Software
+ <tag>9. License Must Not Contaminate Other Software
</tag>
<item>
The license must not place restrictions on other
that all other programs distributed on the same medium
must be free software.
</item>
- <tag>Example Licenses
+ <tag>10. Example Licenses
</tag>
<item>
The "GPL," "BSD," and "Artistic" licenses are examples of
</sect>
<sect id="sections">
- <heading>Categories</heading>
+ <heading>Archive areas</heading>
<sect1 id="main">
- <heading>The main category</heading>
+ <heading>The main archive area</heading>
<p>
Every package in <em>main</em> must comply with the DFSG
</sect1>
<sect1 id="contrib">
- <heading>The contrib category</heading>
+ <heading>The contrib archive area</heading>
<p>
Every package in <em>contrib</em> must comply with the DFSG.
</sect1>
<sect1 id="non-free">
- <heading>The non-free category</heading>
+ <heading>The non-free archive area</heading>
<p>
Packages must be placed in <em>non-free</em> if they are
<heading>Sections</heading>
<p>
- The packages in the categories <em>main</em>,
- <em>contrib</em> and <em>non-free</em> are grouped further
- into <em>sections</em> to simplify handling.
+ The packages in the archive areas <em>main</em>,
+ <em>contrib</em> and <em>non-free</em> are grouped further into
+ <em>sections</em> to simplify handling.
</p>
<p>
- The category and section for each package should be
- specified in the package's <tt>Section</tt> control record
- (see <ref id="f-Section">). 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:
+ The archive area and section for each package should be
+ specified in the package's <tt>Section</tt> control record (see
+ <ref id="f-Section">). 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>
<em>section</em> if the package is in the
- <em>main</em> category,
+ <em>main</em> archive area,
</item>
<item>
- <em>segment/section</em> if the package is in
+ <em>area/section</em> if the package is in
the <em>contrib</em> or <em>non-free</em>
- distribution areas.
+ archive areas.
</item>
</list>
</p>
<p>
The Debian archive maintainers provide the authoritative
list of sections. At present, they are:
- <em>admin</em>, <em>comm</em>,
- <em>devel</em>, <em>doc</em>,
- <em>editors</em>, <em>electronics</em>, <em>embedded</em>,
- <em>games</em>, <em>gnome</em>, <em>graphics</em>,
- <em>hamradio</em>, <em>interpreters</em>, <em>kde</em>,
- <em>libs</em>, <em>libdevel</em>, <em>mail</em>,
- <em>math</em>, <em>misc</em>, <em>net</em>, <em>news</em>,
- <em>oldlibs</em>,
- <em>otherosfs</em>, <em>perl</em>, <em>python</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>.
+ <em>admin</em>, <em>cli-mono</em>, <em>comm</em>, <em>database</em>,
+ <em>devel</em>, <em>debug</em>, <em>doc</em>, <em>editors</em>,
+ <em>electronics</em>, <em>embedded</em>, <em>fonts</em>,
+ <em>games</em>, <em>gnome</em>, <em>graphics</em>, <em>gnu-r</em>,
+ <em>gnustep</em>, <em>hamradio</em>, <em>haskell</em>,
+ <em>httpd</em>, <em>interpreters</em>, <em>java</em>, <em>kde</em>,
+ <em>kernel</em>, <em>libs</em>, <em>libdevel</em>, <em>lisp</em>,
+ <em>localization</em>, <em>mail</em>, <em>math</em>, <em>misc</em>,
+ <em>net</em>, <em>news</em>, <em>ocaml</em>, <em>oldlibs</em>,
+ <em>otherosfs</em>, <em>perl</em>, <em>php</em>, <em>python</em>,
+ <em>ruby</em>, <em>science</em>, <em>shells</em>, <em>sound</em>,
+ <em>tex</em>, <em>text</em>, <em>utils</em>, <em>vcs</em>,
+ <em>video</em>, <em>web</em>, <em>x11</em>, <em>xfce</em>,
+ <em>zope</em>.
</p>
</sect>
<heading>Prompting in maintainer scripts</heading>
<p>
Package maintainer scripts may prompt the user if
- necessary. Prompting should be done by communicating
+ necessary. Prompting must be done by communicating
through a program, such as <prgn>debconf</prgn>, which
conforms to the Debian Configuration Management
- Specification, version 2 or higher. Prompting the user by
- other means, such as by hand<footnote>
- From the Jargon file: by hand 2. By extension,
- writing code which does something in an explicit or
- low-level way for which a presupplied library
- (<em>debconf, in this instance</em>) routine ought
- to have been available.
- </footnote>, is now deprecated.
+ 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>
its copyright and distribution license in the file
<file>/usr/share/doc/<var>package</var>/copyright</file>
(see <ref id="copyrightfile"> for further details). Also see
- <ref id="pkgcopyright"> for further considerations relayed
+ <ref id="pkgcopyright"> for further considerations related
to copyrights for packages.
</p>
</sect>
<item>
<tt>DEB_*_ARCH</tt> (the Debian architecture)
</item>
+ <item>
+ <tt>DEB_*_ARCH_CPU</tt> (the Debian CPU name)
+ </item>
+ <item>
+ <tt>DEB_*_ARCH_OS</tt> (the Debian System name)
+ </item>
<item>
<tt>DEB_*_GNU_TYPE</tt> (the GNU style architecture
specification string)
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.
+ or system information; the <tt>DEB_*_ARCH_CPU</tt> and
+ <tt>DEB_*_ARCH_OS</tt> variables should be used for that.
+ GNU style variables should generally only be used with upstream
+ build systems.
</p>
<sect1 id="debianrules-options">
<p>
Field names are not case-sensitive, but it is usual to
capitalize the field names using mixed case as shown below.
+ Field values are case-sensitive unless the description of the
+ field says otherwise.
</p>
<p>
See <ref id="substvars"> for details.
</p>
+ <p>
+ In addition to the control file syntax described <qref
+ id="controlsyntax">above</qref>, this file may also contain
+ comment lines starting with <tt>#</tt> without any preceding
+ whitespace. All such lines are ignored, even in the middle of
+ continuation lines for a multiline field, and do not end a
+ multiline field.
+ </p>
+
</sect>
<sect id="binarycontrolfiles">
package control file when the source package has the same
name and version as the binary package.
</p>
+
+ <p>
+ Package names (both source and binary,
+ see <ref id="f-Package">) must consist only 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 start with an alphanumeric character.
+ </p>
</sect1>
<sect1 id="f-Maintainer">
</p>
<p>
- Package names must consist only 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 start
- with an alphanumeric character.
+ Binary package names must follow the same syntax and
+ restrictions as source package names. See <ref id="f-Source">
+ for the details.
</p>
</sect1>
values:
<list>
<item>A unique single word identifying a Debian machine
- architecture, see <ref id="arch-spec">.
+ architecture as described in <ref id="arch-spec">.
<item><tt>all</tt>, which indicates an
architecture-independent package.
<item><tt>any</tt>, which indicates a package available
<p>
In the main <file>debian/control</file> file in the source
- package, or in the source package control file
- <file>.dsc</file>, one may specify a list of architectures
- separated by spaces, or the special values <tt>any</tt> or
- <tt>all</tt>.
+ package, this field may contain the special value
+ <tt>any</tt>, the special value <tt>all</tt>, or a list of
+ architectures separated by spaces. If <tt>any</tt> or
+ <tt>all</tt> appear, they must be the entire contents of the
+ field. Most packages will use either <tt>any</tt> or
+ <tt>all</tt>. Specifying a specific list of architectures is
+ for the minority of cases where a program is not portable or
+ is not useful on some architectures, and where possible the
+ program should be made portable instead.
+ </p>
+
+ <p>
+ In the source package control file <file>.dsc</file>, this
+ field may contain either the special value <tt>any</tt> or a
+ list of architectures separated by spaces. If a list is given,
+ it may include (or consist solely of) the special value
+ <tt>all</tt>. In other words, in <file>.dsc</file> files
+ unlike the <file>debian/control</file>, <tt>all</tt> may occur
+ in combination with specific architectures. The
+ <tt>Architecture</tt> field in the source package control file
+ <file>.dsc</file> is generally constructed from the
+ <tt>Architecture</tt> fields in the
+ <file>debian/control</file> in the source package.
</p>
<p>
Specifying <tt>any</tt> indicates that the source package
isn't dependent on any particular architecture and should
compile fine on any one. The produced binary package(s)
- will be specific to whatever the current build architecture
- is.<footnote>
- This is the most often used setting, and is recommended
- for new packages that aren't <tt>Architecture: all</tt>.
- </footnote>
+ will either be specific to whatever the current build
+ architecture is or will be architecture-independent.
+ </p>
+
+ <p>
+ Specifying only <tt>all</tt> indicates that the source package
+ will only build architecture-independent packages. If this is
+ the case, <tt>all</tt> must be used rather than <tt>any</tt>;
+ <tt>any</tt> implies that the source package will build at
+ least one architecture-dependent package.
</p>
<p>
Specifying a list of architectures indicates that the source
will build an architecture-dependent package, and will only
- work correctly on the listed architectures.<footnote>
- This is a setting used for a minority of cases where the
- program is not portable. Generally, it should not be used
- for new packages.
- </footnote>
+ work correctly on the listed architectures. If the source
+ package also builds at least one architecture-independent
+ package, <tt>all</tt> will also be included in the list.
</p>
<p>
field lists the architecture(s) of the package(s)
currently being uploaded. This will be a list; if the
source for the package is also being uploaded, the special
- entry <tt>source</tt> is also present.
+ entry <tt>source</tt> is also present. <tt>all</tt> will be
+ present if any architecture-independent packages are being
+ uploaded. <tt>any</tt> may never occur in the
+ <tt>Architecture</tt> field in the <file>.changes</file>
+ file.
</p>
<p>
</p>
<p>
- In a <file>.changes</file> file, the <tt>Description</tt> field
- contains a summary of the descriptions for the packages being
- uploaded.
+ In a <file>.changes</file> file, the <tt>Description</tt>
+ field contains a summary of the descriptions for the packages
+ being uploaded. For this case, the first line of the field
+ value (the part on the same line as <tt>Description:</tt>) is
+ always empty. The content of the field is expressed as
+ continuation lines, one line per package. Each line is
+ indented by one space and contains the name of a binary
+ package, a space, a hyphen (<tt>-</tt>), a space, and the
+ short description line from that package.
</p>
-
- <p>
- The part of the field before the first newline is empty;
- thereafter each line has the name of a binary package and
- the summary description line from that binary package.
- Each line is indented by one space.
- </p>
-
</sect1>
<sect1 id="f-Distribution">
distribution(s) where this version of the package should
be installed. Valid distributions are determined by the
archive maintainers.<footnote>
- Current distribution names are:
+ Example distribution names in the Debian archive used in
+ <file>.changes</file> files are:
<taglist compact="compact">
- <tag><em>stable</em></tag>
- <item>
- 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).
- </item>
-
<tag><em>unstable</em></tag>
<item>
- 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.
- </item>
-
- <tag><em>testing</em></tag>
- <item>
- 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>.
- </item>
-
- <tag><em>frozen</em></tag>
- <item>
- 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.
+ This distribution value refers to the
+ <em>developmental</em> part of the Debian distribution
+ tree. Most new packages, new upstream versions of
+ packages and bug fixes go into the <em>unstable</em>
+ directory tree.
</item>
<tag><em>experimental</em></tag>
<item>
- 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.
+ 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.
</item>
</taglist>
<p>
- You should list <em>all</em> distributions that the
- package should be installed into.
- </p>
-
- <p>
- More information is available in the Debian Developer's
- Reference, section "The Debian archive".
+ Others are used for updating stable releases or for
+ security uploads. More information is available in the
+ Debian Developer's Reference, section "The Debian
+ archive".
</p>
</footnote>
+ The Debian archive software only supports listing a single
+ distribution. Migration of packages to other distributions is
+ handled outside of the upload process.
</p>
</sect1>
</p>
<p>
- There should be nothing in this field before the first
- newline; all the subsequent lines must be indented by at
- least one space; blank lines must be represented by a line
- consisting only of a space and a full stop.
+ The first line of the field value (the part on the same line
+ as <tt>Changes:</tt>) is always empty. The content of the
+ field is expressed as continuation lines, with each line
+ indented by at least one space. Blank lines must be
+ represented by a line consisting only of a space and a full
+ stop (<tt>.</tt>).
</p>
<p>
<heading><tt>Binary</tt></heading>
<p>
- This field is a list of binary packages.
+ This field is a list of binary packages. Its syntax and
+ meaning varies depending on the control file in which it
+ appears.
</p>
<p>
- When it appears in the <file>.dsc</file> file it is the list
- of binary packages which a source package can produce. It
- does not necessarily produce all of these binary packages
- for every architecture. The source control file doesn't
- contain details of which architectures are appropriate for
- which of the binary packages.
- </p>
-
- <p>
- When it appears in a <file>.changes</file> file it lists the
- names of the binary packages actually being uploaded.
+ When it appears in the <file>.dsc</file> file, it lists binary
+ packages which a source package can produce, separated by
+ commas<footnote>
+ A space after each comma is conventional.
+ </footnote>. It may span multiple lines. The source package
+ does not necessarily produce all of these binary packages for
+ every architecture. The source control file doesn't contain
+ details of which architectures are appropriate for which of
+ the binary packages.
</p>
<p>
- The syntax is a list of binary packages separated by
- commas<footnote>
- A space after each comma is conventional.
- </footnote>. Currently the packages must be separated using
- only spaces in the <file>.changes</file> file.
+ When it appears in a <file>.changes</file> file, it lists the
+ names of the binary packages being uploaded, separated by
+ whitespace (not commas). It may span multiple lines.
</p>
</sect1>
<heading><tt>Installed-Size</tt></heading>
<p>
- This field appears in the control files of binary
- packages, and in the <file>Packages</file> files. It gives
- the total amount of disk space required to install the
- named package.
+ This field appears in the control files of binary packages,
+ and in the <file>Packages</file> files. It gives an estimate
+ of the total amount of disk space required to install the
+ named package. Actual installed size may vary based on block
+ size, file system properties, or actions taken by package
+ maintainer scripts.
</p>
<p>
- The disk space is represented in kilobytes as a simple
- decimal number.
+ The disk space is given as the integer value of the estimated
+ installed size in bytes, divided by 1024 and rounded up.
</p>
</sect1>
<p>
This field contains a list of files with information about
each one. The exact information and syntax varies with
- the context. In all cases the part of the field
- contents on the same line as the field name is empty. The
- remainder of the field is one line per file, each line
- being indented by one space and containing a number of
- sub-fields separated by spaces.
+ the context.
+ </p>
+
+ <p>
+ In all cases, Files is a multiline field. The first line of
+ the field value (the part on the same line as <tt>Files:</tt>)
+ is always empty. The content of the field is expressed as
+ continuation lines, one line per file. Each line must be
+ indented by one space and contain a number of sub-fields,
+ separated by spaces, as described below.
</p>
<p>
In the <file>.dsc</file> file, each line contains the MD5
- checksum, size and filename of the tar file and (if applicable)
- diff file which make up the remainder of the source
- package<footnote>
- That is, the parts which are not the <tt>.dsc</tt>.
- </footnote>.
+ checksum, size and filename of the tar file and (if
+ applicable) diff file which make up the remainder of the
+ source package<footnote>
+ That is, the parts which are not the <tt>.dsc</tt>.
+ </footnote>. For example:
+ <example>
+Files:
+ c6f698f19f2a2aa07dbb9bbda90a2754 571925 example_1.2.orig.tar.gz
+ 938512f08422f3509ff36f125f5873ba 6220 example_1.2-1.diff.gz
+ </example>
The exact forms of the filenames are described
in <ref id="pkg-sourcearchives">.
</p>
<p>
In the <file>.changes</file> file this contains one line per
file being uploaded. Each line contains the MD5 checksum,
- size, section and priority and the filename.
+ size, section and priority and the filename. For example:
+ <example>
+Files:
+ 4c31ab7bfc40d3cf49d7811987390357 1428 text extra example_1.2-1.dsc
+ c6f698f19f2a2aa07dbb9bbda90a2754 571925 text extra example_1.2.orig.tar.gz
+ 938512f08422f3509ff36f125f5873ba 6220 text extra example_1.2-1.diff.gz
+ 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text extra example_1.2-1_i386.deb
+ </example>
The <qref id="f-Section">section</qref>
- and <qref id="f-Priority">priority</qref>
- are the values of the corresponding fields in
- the main source control file. If no section or priority is
- specified then <tt>-</tt> should be used, though section
- and priority values must be specified for new packages to
- be installed properly.
+ and <qref id="f-Priority">priority</qref> are the values of
+ the corresponding fields in the main source control file. If
+ no section or priority is specified then <tt>-</tt> should be
+ used, though section and priority values must be specified for
+ new packages to be installed properly.
</p>
<p>
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
</example>
+ requires <tt>kernel-headers-2.2.10</tt> on all architectures
+ other than hurd-i386 and requires <tt>hurd-dev</tt> and
+ <tt>gnumach-dev</tt> only on hurd-i386.
+ </p>
+
+ <p>
+ If the architecture-restricted dependency is part of a set of
+ alternatives using <tt>|</tt>, that alternative is ignored
+ completely on architectures that do not match the restriction.
+ For example:
+ <example compact="compact">
+Build-Depends: foo [!i386] | bar [!amd64]
+ </example>
+ is equivalent to <tt>bar</tt> on the i386 architecture, to
+ <tt>foo</tt> on the amd64 architecture, and to <tt>foo |
+ bar</tt> on all other architectures.
</p>
<p>
This is done using the <tt>Depends</tt>, <tt>Pre-Depends</tt>,
<tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
<tt>Breaks</tt> and <tt>Conflicts</tt> control file fields.
+ <tt>Breaks</tt> is described in <ref id="breaks">, and
+ <tt>Conflicts</tt> is described in <ref id="conflicts">. The
+ rest are described below.
</p>
<p>
<sect id="breaks">
<heading>Packages which break other packages - <tt>Breaks</tt></heading>
- <p>
- Using <tt>Breaks</tt> may cause problems for upgrades from older
- versions of Debian and should not be used until the stable
- release of Debian supports <tt>Breaks</tt>.
- </p>
-
<p>
When one binary package declares that it breaks another,
<prgn>dpkg</prgn> will refuse to allow the package which
<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. Instead,
- <tt>Breaks</tt> may be used (once <tt>Breaks</tt> is supported
- by the stable release of Debian).
+ <tt>Breaks</tt> may be used.
</p>
</sect>
<sect1 id="fhs">
- <heading>File system Structure</heading>
+ <heading>File System Structure</heading>
<p>
The location of all installed files and directories must
- comply with the File system Hierarchy Standard (FHS),
+ comply with the Filesystem Hierarchy Standard (FHS),
version 2.3, with the exceptions noted below, and except
where doing so would violate other terms of Debian
Policy. The following exceptions to the FHS apply:
<enumlist>
- <item>
- <p>
- Legacy XFree86 servers are permitted to retain the
- configuration file location
- <file>/etc/X11/XF86Config-4</file>.
- </p>
- </item>
<item>
<p>
The optional rules related to user specific
for 64 bit binaries is removed.
</p>
</item>
+ <item>
+ <p>
+ The requirement for object files, internal binaries, and
+ libraries, including <file>libc.so.*</file>, to be located
+ directly under <file>/lib{,32}</file> and
+ <file>/usr/lib{,32}</file> is amended, permitting files
+ to instead be installed to
+ <file>/lib/<var>triplet</var></file> and
+ <file>/usr/lib/<var>triplet</var></file>, where
+ <tt><var>triplet</var></tt> is the value returned by
+ <tt>dpkg-architecture -qDEB_HOST_GNU_TYPE</tt> for the
+ architecture of the package. Packages may <em>not</em>
+ install files to any <var>triplet</var> path other
+ than the one matching the architecture of that package;
+ for instance, an <tt>Architecture: amd64</tt> package
+ containing 32-bit x86 libraries may not install these
+ libraries to <file>/usr/lib/i486-linux-gnu</file>.
+ <footnote>
+ This is necessary in order to reserve the directories for
+ use in cross-installation of library packages from other
+ architectures, as part of the planned deployment of
+ <tt>multiarch</tt>.
+ </footnote>
+ </p>
+ <p>
+ Applications may also use a single subdirectory under
+ <file>/usr/lib/<var>triplet</var></file>.
+ </p>
+ <p>
+ The execution time linker/loader, ld*, must still be made
+ available in the existing location under /lib or /lib64
+ since this is part of the ELF ABI for the architecture.
+ </p>
+ </item>
<item>
<p>
The requirement that
by any particular mail agents. The use of the old
location <file>/var/spool/mail</file> is deprecated, even
though the spool may still be physically located there.
- To maintain partial upgrade compatibility for systems
- which have <file>/var/spool/mail</file> as their physical mail
- spool, packages using <file>/var/mail</file> must depend on
- either <package>libc6</package> (>= 2.1.3-13), or on
- <package>base-files</package> (>= 2.2.0), or on later
- versions of either one of these packages.
</p>
</sect1>
</sect>
<tt>K</tt> prefix, but they too are called with the single
argument <tt>stop</tt>.
</p>
-
- <p>
- Also, if the script name ends in <tt>.sh</tt>, the script
- will be sourced in runlevel <tt>S</tt> rather than being
- run in a forked subprocess, but will be explicitly run by
- <prgn>sh</prgn> in all other runlevels.
- </p>
</sect1>
<sect1>
script must behave sensibly and not fail if the
<file>/etc/default</file> file is deleted.
</p>
+
+ <p>
+ <file>/var/run</file> and <file>/var/lock</file> may be mounted
+ as temporary filesystems<footnote>
+ For example, using the <tt>RAMRUN</tt> and <tt>RAMLOCK</tt>
+ options in <file>/etc/default/rcS</file>.
+ </footnote>, so the <file>init.d</file> scripts must handle this
+ correctly. This will typically amount to creating any required
+ subdirectories dynamically when the <file>init.d</file> script
+ is run, rather than including them in the package and relying on
+ <prgn>dpkg</prgn> to create them.
+ </p>
</sect1>
<sect1>
</p>
<p>
- Note that the same symbol (<tt>"</tt>) is used for the left
- and right quotation marks. A grave accent (<tt>`</tt>) is
- not a quote character; neither is an apostrophe
- (<tt>'</tt>).
+ Note that the same symbol (<tt>"</tt>) <!-- " --> is used
+ for the left and right quotation marks. A grave accent
+ (<tt>`</tt>) is not a quote character; neither is an
+ apostrophe (<tt>'</tt>).
</p>
</item>
</footnote>
</p>
- <p>
- Packages containing shared libraries that may be linked to
- by other packages' binaries, but which for some
- <em>compelling</em> reason can not be installed in
- <file>/usr/lib</file> directory, may install the shared library
- files in subdirectories of the <file>/usr/lib</file> directory,
- in which case they should arrange to add that directory in
- <file>/etc/ld.so.conf</file> in the package's post-installation
- script, and remove it in the package's post-removal script.
- </p>
-
<p>
An ever increasing number of packages are using
<prgn>libtool</prgn> to do their linking. The latest GNU
fi
done
</example>
- The corresponding <tt>dpkg-statoverride --remove</tt>
- calls can then be made unconditionally when the package is
- purged.
+ The corresponding code to remove the override when the package
+ is purged would be:
+ <example>
+for i in /usr/bin/foo /usr/sbin/bar
+do
+ if dpkg-statoverride --list $i >/dev/null 2>&1
+ then
+ dpkg-statoverride --remove $i
+ fi
+done
+ </example>
</p>
</sect1>
</sect>
use <file>/usr/bin/sensible-editor</file> and
<file>/usr/bin/sensible-pager</file> as the 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, and fall back to
- <file>/usr/bin/editor</file> and <file>/usr/bin/pager</file> if the
- variable is not set.
+ <package>sensible-utils</package> package that check the EDITOR
+ and PAGER variables and launch the appropriate program, and fall
+ back to <file>/usr/bin/editor</file>
+ and <file>/usr/bin/pager</file> if the variable is not set.
</p>
<p>
</p>
<p>
- Mailboxes are generally mode 660
- <tt><var>user</var>:mail</tt> unless the system
- administrator 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.
+ Mailboxes are generally either mode 600 and owned by
+ <var>user</var> or mode 660 and owned by
+ <tt><var>user</var>:mail</tt><footnote>
+ There are two traditional permission schemes for mail spools:
+ mode 600 with all mail delivery done by processes running as
+ the destination user, or mode 660 and owned by group mail with
+ mail delivery done by a process running as a system user in
+ group mail. Historically, Debian required mode 660 mail
+ spools to enable the latter model, but that model has become
+ increasingly uncommon and the principle of least privilege
+ indicates that mail systems that use the first model should
+ use permissions of 600. If delivery to programs is permitted,
+ it's easier to keep the mail system secure if the delivery
+ agent runs as the destination user. Debian Policy therefore
+ permits either scheme.
+ </footnote>. The local system administrator may choose a
+ different permission scheme; packages should not make
+ assumptions about the permission and ownership of mailboxes
+ unless required (such as when creating a new mailbox). A MUA
+ may remove a mailbox (unless it has nonstandard permissions) in
+ which case the MTA or another MUA must recreate it if needed.
</p>
<p>
</list>
</item>
- <item>
- Speedo fonts must be placed in
- <file>/usr/share/fonts/X11/Speedo/</file>.
- </item>
-
<item>
Type 1 fonts must be placed in
<file>/usr/share/fonts/X11/Type1/</file>. If font
Subdirectories of <file>/usr/share/fonts/X11/</file>
other than those listed above must be neither
created nor used. (The <file>PEX</file>, <file>CID</file>,
- and <file>cyrillic</file> directories are excepted for
- historical reasons, but installation of files into
- these directories remains discouraged.)
+ <file>Speedo</file>, and <file>cyrillic</file> directories
+ are excepted for historical reasons, but installation of
+ files into these directories remains discouraged.)
</item>
<item>
</p>
</sect1>
- <sect1>
+ <sect1 id="appdefaults">
<heading>Application defaults files</heading>
<p>
<heading>Installation directory issues</heading>
<p>
- Packages using the X Window System should not be
- configured to install files under the
- <file>/usr/X11R6/</file> directory. The
- <file>/usr/X11R6/</file> directory hierarchy should be
+ Historically, packages using the X Window System used a
+ separate set of installation directories from other packages.
+ This practice has been discontinued and packages using the X
+ Window System should now generally be installed in the same
+ directories as any other package. Specifically, packages must
+ not install files under the <file>/usr/X11R6/</file> directory
+ and the <file>/usr/X11R6/</file> directory hierarchy should be
regarded as obsolete.
</p>
<p>
- Programs that use GNU <prgn>autoconf</prgn> and
- <prgn>automake</prgn> are usually easily configured at
- compile time to use <file>/usr/</file> instead of
- <file>/usr/X11R6/</file>, and this should be done whenever
- possible. Configuration files for window managers and
- display managers should be placed in a subdirectory of
- <file>/etc/X11/</file> 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 <file>/etc/</file> directory unless otherwise mandated
- by policy.
+ Include files previously installed under
+ <file>/usr/X11R6/include/X11/</file> should be installed into
+ <file>/usr/include/X11/</file>. For files previously
+ installed into subdirectories of
+ <file>/usr/X11R6/lib/X11/</file>, package maintainers should
+ determine if subdirectories of <file>/usr/lib/</file> and
+ <file>/usr/share/</file> can be used. If not, a subdirectory
+ of <file>/usr/lib/X11/</file> should be used.
</p>
<p>
- The installation of files into subdirectories
- of <file>/usr/X11R6/include/X11/</file> and
- <file>/usr/X11R6/lib/X11/</file> is now prohibited;
- package maintainers should determine if subdirectories of
- <file>/usr/lib/</file> and <file>/usr/share/</file> can be used
- instead.
- </p>
-
- <p>
- Packages should install any relevant files into the
- directories <file>/usr/include/X11/</file> and
- <file>/usr/lib/X11/</file>, but if they do so, they must
- pre-depend on <tt>x11-common (>=
- 1:7.0.0)</tt><footnote>
- <p>
- These libraries used to be all symbolic
- links. However, with <tt>X11R7</tt>,
- <tt>/usr/include/X11</tt> and <tt>/usr/lib/X11</tt>
- are now real directories, and packages
- <strong>should</strong> ship their files here instead
- of in <tt>/usr/X11R6/{include,lib}/X11</tt>.
- <tt>x11-common (>= 1:7.0.0) </tt> is the package
- responsible for converting these symlinks into
- directories.
- </p>
- </footnote>
+ Configuration files for window, display, or session managers
+ or other applications that are tightly integrated with the X
+ Window System may be placed in a subdirectory
+ of <file>/etc/X11/</file> corresponding to the package name.
+ Other X Window System applications should use
+ the <file>/etc/</file> directory unless otherwise mandated by
+ policy (such as for <ref id="appdefaults">).
</p>
</sect1>
</p>
<p>
- Due to limitations in current implementations, all characters
- in the manual page source should be representable in the usual
- legacy encoding for that language, even if the file is
- actually encoded in UTF-8. Safe alternative ways to write many
- characters outside that range may be found in
- <manref name="groff_char" section="7">.
+ If a localized version of a manual page is provided, it should
+ either be up-to-date or it should be obvious to the reader that
+ it is outdated and the original manual page should be used
+ instead. This can be done either by a note at the beginning of
+ the manual page or by showing the missing or changed portions in
+ the original language instead of the target language.
</p>
</sect>
</p>
<p>
- Your package should call <prgn>install-info</prgn> to update
- the Info <file>dir</file> file in its <prgn>postinst</prgn>
- script when called with a <tt>configure</tt> argument, for
- example:
- <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 <file>/usr/share/info/dir</file> 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 <prgn>prerm</prgn>
- script when called with a <tt>remove</tt> argument:
- <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>
+ The <prgn>install-info</prgn> program maintains a directory of
+ installed info documents in <file>/usr/share/info/dir</file> for
+ the use of info readers.<footnote>
+ It was previously necessary for packages installing info
+ documents to run <prgn>install-info</prgn> from maintainer
+ scripts. This is no longer necessary. The installation
+ system now uses dpkg triggers.
+ </footnote>
+ This file must not be included in packages. Packages containing
+ info documents should depend on <tt>dpkg (>= 1.15.4) |
+ install-info</tt> to ensure that the directory file is properly
+ rebuilt during partial upgrades from Debian 5.0 (lenny) and
+ earlier.
+ </p>
+
+ <p>
+ Info documents should contain section and directory entry
+ information in the document for the use
+ of <prgn>install-info</prgn>. The section should be specified
+ via a line starting with <tt>INFO-DIR-SECTION</tt> followed by a
+ space and the section of this info page. The directory entry or
+ entries should be included between
+ a <tt>START-INFO-DIR-ENTRY</tt> line and
+ an <tt>END-INFO-DIR-ENTRY</tt> line. For example:
+ <example>
+INFO-DIR-SECTION Individual utilities
+START-INFO-DIR-ENTRY
+* example: (example). An example info directory entry.
+END-INFO-DIR-ENTRY
+ </example>
+ To determine which section to use, you should look
+ at <file>/usr/share/info/dir</file> on your system and choose
+ the most relevant (or create a new section if none of the
+ current sections are relevant).<footnote>
+ Normally, info documents are generated from Texinfo source.
+ To include this information in the generated info document, if
+ it is absent, add commands like:
+ <example>
+@dircategory Individual utilities
+@direntry
+* example: (example). An example info directory entry.
+@end direntry
+ </example>
+ to the Texinfo source of the document and ensure that the info
+ documents are rebuilt from source during the package build.
+ </footnote>
+ </p>
</sect>
<sect>
</p>
<p>
- Packages in the <em>contrib</em> or <em>non-free</em> categories
- should state in the copyright file that the package is not part
- of the Debian GNU/Linux distribution and briefly explain why.
+ Packages in the <em>contrib</em> or <em>non-free</em> archive
+ areas should state in the copyright file that the package is not
+ part of the Debian GNU/Linux distribution and briefly explain
+ why.
</p>
<p>
<p>
Packages distributed under the UCB BSD license, the Apache
license (version 2.0), the Artistic license, the GNU GPL
- (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and
- the GNU FDL (version 1.2) should refer to the corresponding
+ (version 2 or 3), the GNU LGPL (versions 2, 2.1, or 3), and the
+ GNU FDL (versions 1.2 or 1.3) should refer to the corresponding
files under <file>/usr/share/common-licenses</file>,<footnote>
<p>
In particular,
<file>/usr/share/common-licenses/GPL-3</file>,
<file>/usr/share/common-licenses/LGPL-2</file>,
<file>/usr/share/common-licenses/LGPL-2.1</file>,
- <file>/usr/share/common-licenses/LGPL-3</file>, and
- <file>/usr/share/common-licenses/GFDL-1.2</file>
+ <file>/usr/share/common-licenses/LGPL-3</file>,
+ <file>/usr/share/common-licenses/GFDL-1.2</file>, and
+ <file>/usr/share/common-licenses/GFDL-1.3</file>
respectively.
</p>
</footnote> rather than quoting them in the copyright
</example>
To view the copyright file for a package you could use this command:
<example>
- dpkg --fsys-tarfile <var>filename</var>.deb | tar xOf - \*/copyright | pager
+ dpkg --fsys-tarfile <var>filename</var>.deb | tar xOf - --wildcards \*/copyright | pager
</example>
</p>
</sect>
projects / debian / debian-policy.git / blobdiff