<p>
The Debian archive maintainers provide the authoritative
list of sections. At present, they are:
- <em>admin</em>, <em>base</em>, <em>comm</em>,
- <em>contrib</em>, <em>devel</em>, <em>doc</em>,
+ <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>non-free</em>, <em>oldlibs</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>,
<p>
The <tt>base system</tt> is 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.
+ 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>
- 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).
+ The base system consists of all those packages with priority
+ <tt>required</tt> or <tt>important</tt>. Many of them will
+ be tagged <tt>essential</tt> (see below).
</p>
</sect>
possible is a good idea.
</p>
</item>
+
+ <tag><tt>patch</tt> (optional)</tag>
+ <item>
+ <p>
+ This target performs whatever additional actions are
+ required to make the source ready for editing (unpacking
+ additional upstream archives, applying patches, etc.).
+ It is recommended to be implemented for any package where
+ <tt>dpkg-source -x</tt> does not result in source ready
+ for additional modification. See
+ <ref id="readmesource">.
+ </p>
+ </item>
</taglist>
<p>
or system information; the GNU style variables should be
used for that.
</p>
+
+ <sect1 id="debianrules-options">
+ <heading><file>debian/rules</file> and
+ <tt>DEB_BUILD_OPTIONS</tt></heading>
+
+ <p>
+ Supporting the standardized environment variable
+ <tt>DEB_BUILD_OPTIONS</tt> is recommended. This variable can
+ contain several flags to change how a package is compiled and
+ built. Each flag must be in the form <var>flag</var> or
+ <var>flag</var>=<var>options</var>. If multiple flags are
+ given, they must be separated by whitespace.<footnote>
+ Some packages support any delimiter, but whitespace is the
+ easiest to parse inside a makefile and avoids ambiguity with
+ flag values that contain commas.
+ </footnote>
+ <var>flag</var> must start with a lowercase letter
+ (<tt>a-z</tt>) and consist only of lowercase letters,
+ numbers (<tt>0-9</tt>), and the characters
+ <tt>-</tt> and <tt>_</tt> (hyphen and underscore).
+ <var>options</var> must not contain whitespace. The same
+ tag should not be given multiple times with conflicting
+ values. Package maintainers may assume that
+ <tt>DEB_BUILD_OPTIONS</tt> will not contain conflicting tags.
+ </p>
+
+ <p>
+ The meaning of the following tags has been standardized:
+ <taglist>
+ <tag>noopt</tag>
+ <item>
+ The presence of this tag means that the package should
+ be compiled with a minimum of optimization. For C
+ programs, it is best to add <tt>-O0</tt> to
+ <tt>CFLAGS</tt> (although this is usually the default).
+ Some programs might fail to build or run at this level
+ of optimization; it may be necessary to use
+ <tt>-O1</tt>, for example.
+ </item>
+ <tag>nostrip</tag>
+ <item>
+ This tag means that the debugging symbols should not be
+ stripped from the binary during installation, so that
+ debugging information may be included in the package.
+ </item>
+ <tag>parallel=n</tag>
+ <item>
+ This tag means that the package should be built using up
+ to <tt>n</tt> parallel processes if the package build
+ system supports this.<footnote>
+ Packages built with <tt>make</tt> can often implement
+ this by passing the <tt>-j</tt><var>n</var> option to
+ <tt>make</tt>.
+ </footnote>
+ If the package build system does not support parallel
+ builds, this string must be ignored. If the package
+ build system only supports a lower level of concurrency
+ than <var>n</var>, the package should be built using as
+ many parallel processes as the package build system
+ supports. It is up to the package maintainer to decide
+ whether the package build times are long enough and the
+ package build system is robust enough to make supporting
+ parallel builds worthwhile.
+ </item>
+ </taglist>
+ </p>
+
+ <p>
+ Unknown flags must be ignored by <file>debian/rules</file>.
+ </p>
+
+ <p>
+ The following makefile snippet is an example of how one may
+ implement the build options; you will probably have to
+ massage this example in order to make it work for your
+ package.
+ <example compact="compact">
+CFLAGS = -Wall -g
+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 (,$(filter noopt,$(DEB_BUILD_OPTIONS)))
+ CFLAGS += -O0
+else
+ CFLAGS += -O2
+endif
+ifeq (,$(filter nostrip,$(DEB_BUILD_OPTIONS)))
+ INSTALL_PROGRAM += -s
+endif
+ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+ NUMJOBS = $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
+ MAKEFLAGS += -j$(NUMJOBS)
+endif
+ </example>
+ </p>
+ </sect1>
</sect>
<!-- FIXME: section pkg-srcsubstvars is the same as substvars -->
the file to the list in <file>debian/files</file>.</p>
</sect>
+ <sect id="embeddedfiles">
+ <heading>Convenience copies of code</heading>
+
+ <p>
+ Some software packages include in their distribution convenience
+ copies of code from other software packages, generally so that
+ users compiling from source don't have to download multiple
+ packages. Debian packages should not make use of these
+ convenience copies unless the included package is explicitly
+ intended to be used in this way.<footnote>
+ For example, parts of the GNU build system work like this.
+ </footnote>
+ If the included code is already in the Debian archive in the
+ form of a library, the Debian packaging should ensure that
+ binary packages reference the libraries already in Debian and
+ the convenience copy is not used. If the included code is not
+ already in Debian, it should be packaged separately as a
+ prerequisite if possible.
+ <footnote>
+ Having multiple copies of the same code in Debian is
+ inefficient, often creates either static linking or shared
+ library conflicts, and, most importantly, increases the
+ difficulty of handling security vulnerabilities in the
+ duplicated code.
+ </footnote>
+ </p>
+ </sect>
+
+ <sect id="readmesource">
+ <heading>Source package handling:
+ <file>debian/README.source</file></heading>
+
+ <p>
+ If running <prgn>dpkg-source -x</prgn> on a source package
+ doesn't produce the source of the package, ready for editing,
+ and allow one to make changes and run
+ <prng>dpkg-buildpackage</prgn> to produce a modified package
+ without taking any additional steps, creating a
+ <file>debian/README.source</file> documentation file is
+ recommended. This file should explain how to do all of the
+ following:
+ <enumlist>
+ <item>Generate the fully patched source, in a form ready for
+ editing, that would be built to create Debian
+ packages. Doing this with a <tt>patch</tt> target in
+ <file>debian/rules</file> is recommended; see
+ <ref id="debianrules">.</item>
+ <item>Modify the source and save those modifications so that
+ they will be applied when building the package.</item>
+ <item>Remove source modifications that are currently being
+ applied when building the package.</item>
+ <item>Optionally, document what steps are necessary to
+ upgrade the Debian source package to a new upstream version,
+ if applicable.</item>
+ </enumlist>
+ This explanation should include specific commands and mention
+ any additional required Debian packages. It should not assume
+ familiarity with any specific Debian packaging system or patch
+ management tools.
+ </p>
+
+ <p>
+ This explanation may refer to a documentation file installed by
+ one of the package's build dependencies provided that the
+ referenced documentation clearly explains these tasks and is not
+ a general reference manual.
+ </p>
+
+ <p>
+ <file>debian/README.source</file> may also include any other
+ information that would be helpful to someone modifying the
+ source package. Even if the package doesn't fit the above
+ description, maintainers are encouraged to document in a
+ <file>debian/README.source</file> file any source package with a
+ particularly complex or unintuitive source layout or build
+ system (for example, a package that builds the same source
+ multiple times to generate different binary packages).
+ </p>
+ </sect>
</chapt>
<item><qref id="f-Priority"><tt>Priority</tt></qref> (recommended)</item>
<item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
<item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommended)</item>
+ <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
</list>
</p>
<item><qref id="f-Essential"><tt>Essential</tt></qref></item>
<item><qref id="binarydeps"><tt>Depends</tt> et al</qref></item>
<item><qref id="f-Description"><tt>Description</tt></qref> (mandatory)</item>
+ <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
</list>
</p>
<item><qref id="f-Installed-Size"><tt>Installed-Size</tt></qref></item>
<item><qref id="f-Maintainer"><tt>Maintainer</tt></qref> (mandatory)</item>
<item><qref id="f-Description"><tt>Description</tt></qref> (mandatory)</item>
+ <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
</list>
</p>
</sect>
<item><qref id="sourcebinarydeps"><tt>Build-Depends</tt> et al</qref></item>
<item><qref id="f-Standards-Version"><tt>Standards-Version</tt></qref> (recommended)</item>
<item><qref id="f-Files"><tt>Files</tt></qref> (mandatory)</item>
+ <item><qref id="f-Homepage"><tt>Homepage</tt></qref></item>
</list>
</p>
</p>
<p>
Any parser that interprets the Uploaders field in
- <file>debian/control</file> should permit it to span multiple
- lines<footnote>
- In the future, the Uploaders field in
- <file>debian/control</file> (but not other control files)
- will be permitted to span multiple lines and interpreting
- a multi-line Uploaders field shall be mandatory.
- </footnote>. Line breaks in an Uploaders field that spans
- multiple lines are not significant and the semantics of
- the field are the same as if the line breaks had not been
- present.
+ <file>debian/control</file> must permit it to span multiple
+ lines. Line breaks in an Uploaders field that spans multiple
+ lines are not significant and the semantics of the field are
+ the same as if the line breaks had not been present.
</p>
</sect1>
<sect1>
<heading>Package interrelationship fields:
<tt>Depends</tt>, <tt>Pre-Depends</tt>,
- <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
+ <tt>Recommends</tt>, <tt>Suggests</tt>,
+ <tt>Breaks</tt>, <tt>Conflicts</tt>,
<tt>Provides</tt>, <tt>Replaces</tt>, <tt>Enhances</tt>
</heading>
</p>
</sect1>
+ <sect1 id="f-Homepage">
+ <heading><tt>Homepage</tt></heading>
+
+ <p>
+ The URL of the web site for this package, preferably (when
+ applicable) the site from which the original source can be
+ obtained and any additional upstream documentation or
+ information may be found. The content of this field is a
+ simple URL without any surrounding characters such as
+ <tt><></tt>.
+ </p>
+ </sect1>
+
</sect>
<sect>
</sect>
<sect id="idempotency">
- <heading>Maintainer scripts Idempotency</heading>
+ <heading>Maintainer scripts idempotency</heading>
<p>
It is necessary for the error recovery procedures that the
<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>
+ [<tt>removing</tt> <var>conflicting-package</var>
+ <var>version</var>]
</item>
</list>
<item>
<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
<tt>in-favour</tt> <var>package-being-installed</var>
- <var>version</var> <tt>removing</tt>
+ <var>version</var> [<tt>removing</tt>
<var>conflicting-package</var>
- <var>version</var>
+ <var>version</var>]
</item>
</list>
</item>
<item>
- If a "conflicting" package is being removed at the same time:
+ If a "conflicting" package is being removed at the same time,
+ or if any package will be broken (due to <tt>Breaks</tt>):
<enumlist>
<item>
- If any packages depended on that conflicting
- package and <tt>--auto-deconfigure</tt> is
+ If <tt>--auto-deconfigure</tt> is
+ specified, call, for each package to be deconfigured
+ due to <tt>Breaks</tt>:
+ <example compact="compact">
+<var>deconfigured's-prerm</var> deconfigure \
+ in-favour <var>package-being-installed</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>
+ </example>
+ The deconfigured packages are marked as
+ requiring configuration, so that if
+ <tt>--install</tt> is used they will be
+ configured again if possible.
+ </item>
+ <item>
+ If any packages depended on a conflicting
+ package being removed and <tt>--auto-deconfigure</tt> is
specified, call, for each such package:
<example compact="compact">
<var>deconfigured's-prerm</var> deconfigure \
configured again if possible.
</item>
<item>
- To prepare for removal of the conflicting package, call:
+ To prepare for removal of each conflicting package, call:
<example compact="compact">
<var>conflictor's-prerm</var> remove \
in-favour <var>package</var> <var>new-version</var>
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
+ disambiguate; it is not otherwise significant. All of the
+ relationship fields may span multiple lines. 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.
+ each open parenthesis. When wrapping a relationship field, it
+ is conventional to do so after a comma and before the space
+ following that comma.
</p>
<p>
<p>
This is done using the <tt>Depends</tt>, <tt>Pre-Depends</tt>,
- <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt> and
- <tt>Conflicts</tt> control file fields.
+ <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
+ <tt>Breaks</tt> and <tt>Conflicts</tt> control file fields.
</p>
<p>
- These six fields are used to declare a dependency
+ These seven 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.)
+ <tt>Enhances</tt> and <tt>Breaks</tt>, they appear in the
+ depending (binary) package's control file.
+ (<tt>Enhances</tt> appears in the recommending package's
+ control file, and <tt>Breaks</tt> appears in the version of
+ depended-on package which causes the named package to
+ break).
</p>
<p>
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>.)
+ to <prgn>dpkg</prgn> such as <prgn>apt-get</prgn>,
+ <prgn>aptitude</prgn>, and <prgn>dselect</prgn>.)
</p>
<p>
(based on rules below), and some packages may not be able to
rely on their dependencies being present when being
installed or removed, depending on which side of the break
- of the circular dependcy loop they happen to be on. If one
+ of the circular dependency loop they happen to be on. If one
of the packages in the loop has no postinst script, then the
cycle will be broken at that package, so as to ensure that
all postinst scripts run with the dependencies properly
</p>
</sect>
+ <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
+ declares <tt>Breaks</tt> be installed unless the broken
+ package is deconfigured first, and it will refuse to
+ allow the broken package to be reconfigured.
+ </p>
+
+ <p>
+ A package will not be regarded as causing breakage 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 that
+ they break their own package name or a virtual package which
+ they provide (see below): this does not count as a real
+ breakage.
+ </p>
+
+ <p>
+ Normally a <tt>Breaks</tt> entry will have an "earlier than"
+ version clause; such a <tt>Breaks</tt> is introduced in the
+ version of an (implicit or explicit) dependency which
+ violates an assumption or reveals a bug in earlier versions
+ of the broken package. This use of <tt>Breaks</tt> will
+ inform higher-level package management tools that broken
+ package must be upgraded before the new one.
+ </p>
+
+ <p>
+ If the breaking package also overwrites some files from the
+ older package, it should use <tt>Replaces</tt> (not
+ <tt>Conflicts</tt>) to ensure this goes smoothly.
+ </p>
+ </sect>
+
<sect id="conflicts">
<heading>Conflicting binary packages - <tt>Conflicts</tt></heading>
"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.
+ 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).
</p>
</sect>
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>Pre-Depends</tt>, <tt>Breaks</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>
- If a dependency or a conflict has a version number attached
+ If a relationship field 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.
+ for a conflict or breakage) - 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>
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.hourly
/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,
+ executed on an hourly, daily, weekly, or monthly basis,
respectively. The exact times are listed in
<file>/etc/crontab</file>.</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.
+ In addition, they must 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
+ If a certain job has to be executed at some other frequency or
+ at a specific time, the package should install a file
<file>/etc/cron.d/<var>package</var></file>. This file uses the
same syntax as <file>/etc/crontab</file> and is processed by
<prgn>cron</prgn> automatically. The file must also be
<p>
Although binaries in the build tree should be compiled with
- debugging information by default, it can often be difficult
- to debug programs if they are also subjected to compiler
- optimization. For this reason, it is recommended to support
- the standardized environment
- variable <tt>DEB_BUILD_OPTIONS</tt>. This variable can
- contain several flags to change how a package is compiled
- and built.
- </p>
-
- <p>
- <taglist>
- <tag>noopt</tag>
- <item>
- The presence of this string means that the package
- should be compiled with a minimum of optimization.
- For C programs, it is best to add <tt>-O0</tt>
- to <tt>CFLAGS</tt> (although this is usually the
- default). Some programs might fail to build or run at
- this level of optimization; it may be necessary to
- use <tt>-O1</tt>, for example.
- </item>
- <tag>nostrip</tag>
- <item>
- This string means that the debugging symbols should
- not be stripped from the binary during installation,
- so that debugging information may be included in the package.
- </item>
- </taglist>
- </p>
-
- <p>
- The following makefile snippet is an example of how one may
- implement the build options; you will probably have to
- massage this example in order to make it work for your
- package.
- <example compact="compact">
-CFLAGS = -Wall -g
-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 noopt,$(DEB_BUILD_OPTIONS)))
-CFLAGS += -O0
-else
-CFLAGS += -O2
-endif
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-INSTALL_PROGRAM += -s
-endif
- </example>
+ debugging information by default, it can often be difficult to
+ debug programs if they are also subjected to compiler
+ optimization. For this reason, it is recommended to support the
+ standardized environment variable <tt>DEB_BUILD_OPTIONS</tt>
+ (see <ref id="debianrules-options">). This variable can contain
+ several flags to change how a package is compiled and built.
</p>
<p>
</p>
<p>
- Note that a script that embeds configuration information
- (such as most of the files in <file>/etc/default</file> and
- <file>/etc/cron.{daily,weekly,monthly}</file>) is de-facto a
- configuration file and should be treated as such.
+ As noted elsewhere, <file>/etc/init.d</file> scripts,
+ <file>/etc/default</file> files, scripts installed in
+ <file>/etc/cron.{hourly,daily,weekly,monthly}</file>, and cron
+ configuration installed in <file>/etc/cron.d</file> must be
+ treated as configuration files. In general, any script that
+ embeds configuration information is de-facto a configuration
+ file and should be treated as such.
</p>
</sect1>
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
be present in the future.
</footnote>
</p>
+
+ <p>
+ Manual pages in locale-specific subdirectories of
+ <file>/usr/share/man</file> should use either UTF-8 or the usual
+ legacy encoding for that language (normally the one corresponding
+ to the shortest relevant locale name in
+ <file>/usr/share/i18n/SUPPORTED</file>). For example, pages under
+ <file>/usr/share/man/fr</file> should use either UTF-8 or
+ ISO-8859-1.<footnote>
+ <prgn>man</prgn> will automatically detect whether UTF-8 is in
+ use. In future, all manual pages will be required to use
+ UTF-8.
+ </footnote>
+ </p>
+
+ <p>
+ A country name (the <tt>DE</tt> in <tt>de_DE</tt>) should not be
+ included in the subdirectory name unless it indicates a
+ significant difference in the language, as this excludes
+ speakers of the language in other countries.<footnote>
+ At the time of writing, Chinese and Portuguese are the main
+ languages with such differences, so <file>pt_BR</file>,
+ <file>zh_CN</file>, and <file>zh_TW</file> are all allowed.
+ </footnote>
+ </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">.
+ </p>
</sect>
<sect>
In addition, the copyright file must say where the upstream
sources (if any) were obtained. It should name the original
authors of the package and the Debian maintainer(s) who were
- involved with its creation.</p>
+ involved with its creation.
+ </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.
+ </p>
<p>
A copy of the file which will be installed in
</p>
<p>
- Packages distributed under the UCB BSD license, 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 files under
- <file>/usr/share/common-licenses</file>,<footnote>
+ 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
+ files under <file>/usr/share/common-licenses</file>,<footnote>
<p>
In particular,
<file>/usr/share/common-licenses/BSD</file>,
+ <file>/usr/share/common-licenses/Apache-2.0</file>,
<file>/usr/share/common-licenses/Artistic</file>,
<file>/usr/share/common-licenses/GPL-2</file>,
<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/GFDL-1.2</file>
respectively.
</p>
</footnote> rather than quoting them in the copyright
</book>
</debiandoc>
+<!-- Local variables: -->
+<!-- indent-tabs-mode: t -->
+<!-- End: -->
<!-- vim:set ai et sts=2 sw=2 tw=76: -->
<h2>The checklist</h2>
<pre>
+3.7.4.0 unreleased
+
+ * The base section has been removed. contrib and non-free have been
+ removed from the section list; they are only categories. The base
+ system is now defined by priority. [2.4, 3.7]
+ * If dpkg-source -x doesn't provide the source that will be compiled,
+ a debian/rules patch target is recommended and should do whatever
+ else is necessary. [4.9]
+ * Standardized the format of DEB_BUILD_OPTIONS. Specified permitted
+ characters for tags, required that tags be whitespace-separated,
+ allowed packages to assume non-conflicting tags, and required
+ unknown flags be ignored. [4.9.1, 10.1]
+ * Added parallel=n to the standardized DEB_BUILD_OPTIONS tags,
+ indicating that a package should be built using up to n parallel
+ processes if the package supports it [4.9.1]
+ * Debian packages should not use convience copies of code from other
+ packages unless the included package is explicitly intended to be
+ used that way. [4.13]
+ * If dpkg-source -x doesn't produce source ready for editing and
+ building with dpkg-buildpackage, packages should include a
+ debian/README.source file explaining how to generate the patched
+ source, add a new modification, and remove an existing
+ modification. This file may also be used to document packaging a
+ new upstream release and any other complexity of the Debian build
+ process. [4.14]
+ * The Uploaders field in debian/control may be wrapped. [5.6.3]
+ * New Homepage field for upstream web sites. [5.6.23]
+ * The Breaks field declares that this package breaks another and
+ prevents installation of the breaking package unless the package
+ named in Breaks is deconfigured first. This field should not be
+ used until the dpkg in Debian stable supports it. [6.5, 6.6, 7]
+ * Files in /etc/cron.{hourly,daily,weekly,monthly} must be
+ configuration files (upgraded from should). Mention the hourly
+ directory. [9.5]
+ * Manual pages in locale-specific directories should use either the
+ legacy encoding for that directory or UTF-8. Country names should
+ not be included in locale-specific manual page directories unless
+ indicating a significant difference in the language. All
+ characters in the manual page source should be representable in the
+ legacy encoding for a locale even if the man page is encoded in
+ UTF-8. [12.1]
+ * The Apache 2.0 license is now in common-licenses and should be
+ referenced rather than quoted in debian/copyright. [12.5]
+ * Packages in contrib and non-free should state in the copyright file
+ that the package is not part of Debian GNU/Linux and briefly
+ explain why. [12.5]
+
3.7.3.0 Dec 2007
+
* Package version numbers may contain tildes, which sort before
anything, even the end of a part. [5.6.12]
* Scripts may assume that /bin/sh supports local (at a basic level)
a gettext-based system such as po-debconf. [3.9.1]
* GFDL 1.2, GPL 3, and LGPL 3 are now in common-licenses and should
be referenced rather than quoted in debian/copyright. [12.5]
+
3.7.2.2 Oct 2006
+
* Maintainer scripts must not be world writeable (up from a
should to a must) [6.1]
+
3.7.2.0 Apr 2006
+
* Revert the cgi-lib change. [11.5]
3.7.1.0 Apr 2006
+
* It is now possible to create shared libraries without
relocatable code (using -fPIC) in certain exceptional cases,
provided some procedures are followed, and for creating static
must pre-depend on x11-common (>= 1:7.0.0) [11.8.7]
3.7.0.0 Apr 2006
+
* Packages shipping web server CGI files are expected to install
them in /usr/lib/cgi-lib/ directories. This location change
perhaps should be documented in NEWS [11.5]
/usr/share/fonts/X11/ now, and /usr/X11R6 is gone.
[ 11.8.5.2, 11.8.7, etc]
-
3.6.2.0 2005
+
* Recommend doc-base, and not menu, for registering package documentation.
* Run time support programs should live in subdirectories of
/usr/lib/ or /usr/share, and preferably the shared lib is named
allow packages to share image files with the web server [11.5]
3.6.1.0 Aug 2003
+
+ Prompting the user should be done using debconf. Non debconf
user prompts are now deprecated. [3.10.1]
- Window managers compliant with the Window Manager Specification
Project may add 40 points for ranking in the alternatives [11.8.4]
-
3.5.9.0 Mar 2003
- The section describing the Description: package field once again has
example files can be installed into <tt>/usr/share/doc/package</tt>
(rather than <tt>/usr/share/doc/package/examples</tt>). [12.6]
-
3.5.8.0 Nov 2002
- It is no longer necessary to keep a log of changes to the upstream
- There are new rules for build-indep/build-arch targets and
there is a new Build-Depend-Indep semantic. [7]
-
3.5.5.0 May 2001
- Manpages should not rely on header information to have
* OpenMotif linked binaries have the same rules as
OSF/Motif-linked ones [11.8.8]
-
3.5.4.0 Apr 2001
- The system-wide mail directory is now /var/mail, no longer
programs and modules should follow the current Perl policy
[11.9; perl-policy]
-
3.5.3.0 Apr 2001
- Build-Depends arch syntax has been changed to be less
symbolic links from /usr/share/doc/<package>/examples as
needed [10.7.3]
-
3.5.2.0 Feb 2001
- X app-defaults directory has moved from
/usr/X11R6/lib/X11/app-defaults to /etc/X11/app-defaults [11.8.6]
-
3.5.1.0 Feb 2001
- dpkg-shlibdeps now uses objdump, so shared libraries have to be
run through dpkg-shlibdeps as well as executables [8.1]
-
3.5.0.0 Jan 2001
- Font packages for the X Window System must now declare a
dependency on xutils (>= 4.0.2) [11.8.5]
-
3.2.1.1 Jan 2001
- Daemon startup scripts in /etc/init.d/ should not contain
- Much of the packaging manual has now been imported into the
policy document
-
3.2.1.0 Aug 00
- A package of priority standard or higher may provide two
binaries, one compiled with support for the X Window System,
and the other without [11.8.1]
-
3.2.0.0 Aug 00
- By default executables should not be built with the debugging
always creating the shared lib before the symlink, so the unpack
order be correct [8]
-
3.1.1.0 Nov 1999
- Correction to semantics of architecture lists in Build-Depends
etc. Should not affect many packages [7.1]
-
3.1.0.0 Oct 1999
- /usr/doc/<package> has to be a symlink pointing to
- Description of how to handle version numbers based on dates
added [3.2.1]
-
3.0.1.0 Jul 1999
- Added the clarification that the .la files are essential for the
packages using libtool's libltdl library, in which case the
.la files must go in the run-time library package [10.2]
-
3.0.0.0 Jun 1999
- Debian formally moves from the FSSTND to the FHS. This is a