<abstract>
This manual describes the policy requirements for the Debian
- GNU/Linux distribution. This includes the structure and
- contents of the Debian archive and several design issues of the
- operating system, as well as technical requirements that each
- package must satisfy to be included in the distribution. The
- policy package itself is maintained by a group of maintainers
- that have no editorial powers. At the moment, the list of
- maintainers is:
+ GNU/Linux distribution. This includes the structure and
+ contents of the Debian archive and several design issues of
+ the operating system, as well as technical requirements that
+ each package must satisfy to be included in the distribution.
+ The policy package itself is maintained by a group of
+ maintainers that have no editorial powers. The current list
+ of maintainers is:
<enumlist>
<item>
<p>Julian Gilbey <email>jdg@debian.org</email></p>
packages, nor is it exhaustive where it comes to describing
the behavior of the packaging system. Instead, this manual
attempts to define the interface to the package management
- system that the developers have to be conversant with.
- <footnote>
+ system that the developers have to be conversant with.<footnote>
<p>
Informally, the criteria used for inclusion is that the
material meet one of the following requirements:
<em>normal</em> or <em>important</em>
(for <em>should</em> or <em>recommended</em> directive
violations) and <em>wishlist</em> (for <em>optional</em>
- items). <footnote>
+ items).<footnote>
<p>Compare RFC 2119. Note, however, that these words are
used in a different way in this document.</p>
</footnote>
<item>
<p>
must meet all policy requirements presented in this
- manual that it is possible for them to meet.
- <footnote>
+ manual that it is possible for them to meet.<footnote>
<p>
It is possible that there are policy
requirements which the package is unable to
expectation is that an experienced Unix person who
found it missing would say `What on earth is going on,
where is <prgn>foo</prgn>?', it must be an
- <tt>important</tt> package.
- <footnote>
+ <tt>important</tt> package.<footnote>
<p>
This is an important criterion because we are
trying to produce, amongst other things, a free
<email>packages@qa.debian.org</email> takes over the
maintainership of the package until someone else
volunteers for that task. These packages are called
- <em>orphaned packages</em>.
- <footnote>
+ <em>orphaned packages</em>.<footnote>
<p>
The detailed procedure for doing this gracefully can
be found in the Debian Developer's Reference, either
<prgn>debconf</prgn>, which conforms to the Debian
Configuration management specification, version 2 or
higher. These are included in the
- <file>debconf_specification</file> files in the
+ <tt>debconf_specification</tt> files in the
<package>debian-policy</package> package.
You may also find this file on the FTP site
<ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/debconf_specification.txt.gz</ftppath>
- or on your local mirror.
- <footnote>
+ or on your local mirror.<footnote>
<p>
- 2.5% of Debian packages [see <url
+ 4% of Debian packages [see <url
id="http://kitenet.net/programs/debconf/stats/"
name="Debconf stats">] currently use
<package>debconf</package> to prompt the user at
<p>
Packages which use the Debian Configuration management
specification may contain an additional
- <file>config</file> script and a <file>templates</file>
+ <prgn>config</prgn> script and a <tt>templates</tt>
file in their control archive. The <prgn>config</prgn>
script might be run before the <prgn>preinst</prgn>
script, and before the package is unpacked or any of its
dependancies or pre-dependancies are satisfied.
Therefore it must work using only the tools present in
- <em>essential</em> packages.
- <footnote>
+ <em>essential</em> packages.<footnote>
<p>
<package>Debconf</package> or another tool that
implements the Debian Configuration management
<p>
In the source package's <tt>Standards-Version</tt> control
- field, you must specify the most recent version number of
- this policy document with which your package complies.
- The current version number is &version;.
+ field, you should specify the most recent version number
+ of this policy document with which your package complied
+ when it was last updated. The current version number is
+ &version;.
</p>
<p>
Thus only the first three components of the policy version
are significant in the <em>Standards-Version</em> control
field, and so either these three components or the all
- four components may be specified.
- <footnote>
+ four components may be specified.<footnote>
<p>
In the past, people specified the full version number
in the Standards-Version field, for example `2.3.0.0'.
available and update your package, if necessary. When your
package complies with the new standards you should update the
<tt>Standards-Version</tt> source package field and
- release it.
- <footnote>
+ release it.<footnote>
<p>
See the file <tt>upgrading-checklist</tt> for
information about policy which has changed between
an informational list can be found in
<tt>/usr/share/doc/build-essential/list</tt> (which is
contained in the <tt>build-essential</tt>
- package).
- <footnote>
+ package).<footnote>
<p>Rationale:
<list compact="compact">
<item>
should list only those packages explicitly required by the
build. It is not necessary to list packages which are
required merely because some other package in the list of
- build-time dependencies depends on them.
- <footnote>
+ build-time dependencies depends on them.<footnote>
<p>
The reason for this is that dependencies change, and
you should list all those packages, and <em>only</em>
<p>
In non-experimental packages you must use a format for
<tt>debian/changelog</tt> which is supported by the most
- recent released version of <prgn>dpkg</prgn>.
- <footnote>
+ recent released version of <prgn>dpkg</prgn>.<footnote>
<p>
If you wish to use an alternative format, you may do
so as long as you include a parser for it in your
this contains the (space-separated) name(s) of the
distribution(s) where this version of the package should
be installed. Valid distributions are determined by the
- archive maintainers.
- <footnote>
+ archive maintainers.<footnote>
Current distribution names are:
<taglist compact="compact">
<tag><em>stable</em></tag>
<taglist>
<tag><var>epoch</var></tag>
<item>
-
<p>
This is a single (generally small) unsigned integer. It
may be omitted, in which case zero is assumed. If it is
of older versions of a package, and also a package's
previous version numbering schemes, to be left behind.
</p>
-
</item>
<tag><var>upstream_version</var></tag>
<item>
-
<p>
This is the main part of the version number. It is
usually the version number of the original (`upstream')
<p>
The <var>upstream_version</var> may contain only
- alphanumerics
- <footnote>
+ alphanumerics<footnote>
<p>Alphanumerics are <tt>A-Za-z0-9</tt> only.</p>
</footnote>
and the characters <tt>.</tt> <tt>+</tt> <tt>-</tt>
<tag><var>debian_revision</var></tag>
<item>
-
<p>
This part of the version number specifies the version of
the Debian package based on the upstream version. It
<p>
Maintainers should preserve the modification times of the
upstream source files in a package, as far as is reasonably
- possible.
- <footnote>
+ possible.<footnote>
<p>
The rationale is that there is some information conveyed
by knowing the age of the file, for example, you could
<tt>touch build</tt> when the build process is
complete. This will ensure that if <tt>debian/rules
build</tt> is run again it will not rebuild the whole
- program.
- <footnote>
+ program.<footnote>
<p>
Another common way to do this is for <prgn>build</prgn>
to depend on <prgn>build-stamp</prgn> and to do
<p>
The <prgn>binary</prgn> targets must be invoked as
- root.
- <footnote>
+ root.<footnote>
<p>
The <prgn>fakeroot</prgn> package often allows one
to build a package correctly even without being
<tag><tt>clean</tt></tag>
<item>
-
<p>
This must undo any effects that the <prgn>build</prgn>
and <prgn>binary</prgn> targets may have had, except
<tag><tt>get-orig-source</tt> (optional)</tag>
<item>
-
<p>
This target fetches the most recent version of the
original source package from a canonical archive site
<p>
This file records the changes to the Debian-specific parts of the
- package
- <footnote>
+ package<footnote>
<p>
Though there is nothing stopping an author who is also
the Debian maintainer from using it for all their
<tt><var>keyword</var>=<var>value</var></tt> settings in the
<prgn>dpkg</prgn> changelog format (though there is
currently only one useful <var>keyword</var>,
- <tt>urgency</tt>).
- <footnote>
+ <tt>urgency</tt>).<footnote>
<p>
Usual urgency values are <tt>low</tt>, <tt>medium</tt>,
<tt>high</tt> and <tt>critical</tt>. They have an
System (BTS), they may be automatically closed on the
inclusion of this package into the Debian archive by
including the string: <tt>closes: Bug#<var>nnnnn</var></tt>
- in the change details.
- <footnote>
+ in the change details.<footnote>
<p>
To be precise, the string should match the following
Perl regular expression:
</p>
<p>
- The <var>date</var> should be in RFC822 format
- <footnote>
+ The <var>date</var> should be in RFC822 format<footnote>
<p>
This is generated by the <prgn>822-date</prgn>
program.
<p>
It should not exist in a shipped source package, and so it
(and any backup files or temporary files such as
- <tt>files.new</tt>
- <footnote>
+ <tt>files.new</tt><footnote>
<p>
<tt>files.new</tt> is used as a temporary file by
<prgn>dpkg-gencontrol</prgn> and
</heading>
<p>
- The source package may not contain any hard links
- <footnote>
+ The source package may not contain any hard links<footnote>
<p>
This is not currently detected when building source
packages, but only when extracting
work.
</p>
</footnote>, device special files, sockets or setuid or
- setgid files.
- <footnote>
+ setgid files.<footnote>
<p>
Setgid directories are allowed.
</p>
<p>
The description field needs to make sense to anyone, even
people who have no idea about any of the things the
- package deals with.
- <footnote>
+ package deals with.<footnote>
<p>
The blurb that comes with a program in its
announcements and/or <prgn>README</prgn> files is
aborted half way through for some reason, the second call
should merely do the things that were left undone the first
time, if any, and exit with a success status if everything
- is OK.
- <footnote>
+ is OK.<footnote>
<p>
This is so that if an error occurs, the user interrupts
<prgn>dpkg</prgn> or some other unforeseen circumstance
system administrator to understand. It can easily
lead to `missing' programs if, for example, a package
is installed which overwrites a file from another
- package, and is then removed again.
- <footnote>
+ package, and is then removed again.<footnote>
<p>
Part of the problem is due to what is arguably a
bug in <prgn>dpkg</prgn>.
<taglist>
<tag><tt>Depends</tt></tag>
<item>
-
<p>
This declares an absolute dependency. A package will
not be configured unless all of the packages listed in
<tag><tt>Suggests</tt></tag>
<item>
-
<p>
This is used to declare that one package may be more
useful with one or more others. Using this field
<tag><tt>Pre-Depends</tt></tag>
<item>
-
<p>
This field is like <tt>Depends</tt>, except that it
also forces <prgn>dpkg</prgn> to complete installation
<prgn>ld-linux.so.*</prgn>) can find the library between the
time that <prgn>dpkg</prgn> installs it and the time that
<prgn>ldconfig</prgn> is run in the <prgn>postinst</prgn>
- script.
- <footnote>
+ script.<footnote>
<p>
The package management system requires the library to be
placed before the symbolic link pointing to it in the
Any package installing shared libraries in one of the default
library directories of the dynamic linker (which are currently
<tt>/usr/lib</tt> and <tt>/lib</tt>) or a directory that is
- listed in <tt>/etc/ld.so.conf</tt>
- <footnote>
+ listed in <tt>/etc/ld.so.conf</tt><footnote>
<p>
These are currently
<list compact="compact">
any shared libraries or compiled binaries, it must run
<prgn>dpkg-shlibdeps</prgn> on these to determine the
libraries used and hence the dependencies needed by this
- package.
- <footnote>
+ package.<footnote>
<p>
In the past, the shared libraries linked to were
determined by calling <prgn>ldd</prgn>, but now
control file area of the temporary build directory and
given the name <tt>shlibs</tt>. These files give
details of any shared libraries included in the
- package.
- <footnote>
+ package.<footnote>
<p>
An example may help here. Let us say that the
source package <tt>foo</tt> generates two binary
debian/tmp/usr/lib/*
</example>
Otherwise, you will need to explicitly list the compiled
- binaries and libraries.
- <footnote>
+ binaries and libraries.<footnote>
<p>
If you are using <tt>debhelper</tt>, the
<prgn>dh_shlibdeps</prgn> program will do this work for
exactly match for the library to be recognized by the
dynamic linker, and is usually of the form
<tt><var>name</var>.so.<var>major-version</var></tt>, in our
- example, <tt>libz.so.1</tt>.
- <footnote>
+ example, <tt>libz.so.1</tt>.<footnote>
<p>
This can be determined using the command
<example compact="compact">
An alternative way of doing this is to create the
<tt>shlibs</tt> file in the control area directly from
<tt>debian/rules</tt> without using a <tt>debian/shlibs</tt>
- file at all,
- <footnote>
+ file at all,<footnote>
<p>
This is what <prgn>dh_makeshlibs</prgn> in the
<tt>debhelper</tt> suite does.
maintainer scripts and not be included in the
<tt>.deb</tt> archive. These scripts must not fail if
either of these operations fail.
- <footnote>
- <p>
- In the future, it may be possible to tell
- <prgn>dpkg</prgn> not to unpack files matching certain
- patterns, so that the directories can be included in
- the <tt>.deb</tt> packages and system administrators
- who do not wish these directories in
- <tt>/usr/local</tt> do not need to have them.)
- </p>
- </footnote>
</p>
<p>
reloaded without actually stopping and restarting
the service,</p></item>
- <tag><tt>force-reload</tt></tag> <item><p>cause the
- configuration to be reloaded if the service supports
- this, otherwise restart the service.</p></item>
+ <tag><tt>force-reload</tt></tag>
+ <item><p>cause the configuration to be reloaded if the
+ service supports this, otherwise restart the
+ service.</p></item>
</taglist>
The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>, and
the environment variable <tt>DEB_BUILD_OPTIONS</tt> contains
the string <tt>nostrip</tt>, do not strip the files at
installation time. This allows one to generate a package
- with debugging information included.
- <footnote>
+ with debugging information included.<footnote>
<p>
Rationale: Using <tt>-g</tt> by default causes wasted
CPU cycles since the information is stripped away
needed for relocation processing.) Shared libraries can
function perfectly well when stripped, since the symbols for
dynamic linking are in a separate part of the ELF object
- file.
- <footnote>
+ file.<footnote>
<p>
You might also want to use the options
<tt>--remove-section=.comment</tt> and
building a separate package to support debugging.
</p>
+ <p>
+ Shared object files (often <tt>.so</tt> files) that are not
+ public libraries, that is, they are not meant to be linked
+ to by third party executables (binaries of other packages),
+ should be installed in subdirectories of the
+ <tt>/usr/lib</tt> directory. Such files are exempt from the
+ rules that govern ordinary shared libraries, except that
+ they must not be installed executable and should be
+ stripped.<footnote>
+ <p>
+ A common example are the so-called ``plug-ins'',
+ internal shared objects that are dynamically loaded by
+ programs using <manref name="dlopen" section="3">.
+ </p>
+ </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
+ <tt>/usr/lib</tt> directory, may install the shared library
+ files in subdirectories of the <tt>/usr/lib</tt> directory,
+ in which case they should arrange to add that directory in
+ <tt>/etc/ld.so.conf</tt> 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
those files, which contain a lot of useful information about
a library (such as library dependency information for static
linking). Also, they're <em>essential</em> for programs
- using <tt>libltdl</tt>.
- <footnote>
+ using <tt>libltdl</tt>.<footnote>
<p>
Although <prgn>libtool</prgn> is fully capable of
linking against shared libraries which don't have
for each library every time it is linked. With the
advent of <prgn>libtool</prgn> version 1.4 (and to a
lesser extent <prgn>libtool</prgn> version 1.3), the
- <tt>.la</tt> files will also store information about
+ <tt>.la</tt> files also store information about
inter-library dependencies which cannot necessarily be
derived after the <tt>.la</tt> file is deleted.
</p>
libraries you need to create two packages:
<tt><var>libraryname</var><var>soversion</var></tt>, where
<tt><var>soversion</var></tt> is the version number in the
- soname of the shared library
- <footnote>
+ soname of the shared library<footnote>
<p>
The soname is the shared object name: it's the thing
that has to match exactly between building an executable
<p>
The standard shell interpreter <tt>/bin/sh</tt> can be a
symbolic link to any POSIX compatible shell, if <tt>echo
- -n</tt> does not generate a newline.
- <footnote>
+ -n</tt> does not generate a newline.<footnote>
<p>
Debian policy specifies POSIX behavior for
<tt>/bin/sh</tt>, but <tt>echo -n</tt> has widespread
scripting languages. See <em>Csh Programming Considered
Harmful</em>, one of the <tt>comp.unix.*</tt> FAQs, which
can be found at <url
- id="http://language.perl.com/versus/csh.whynot">.
- <footnote>
+ id="http://language.perl.com/versus/csh.whynot">.<footnote>
<p>
It can also be found on
<url id="http://www.cpan.org/doc/FMTEYEWTK/versus/csh.whynot">
already exists.</p>
<p>
- The Debian base distribution provides the
- <prgn>tempfile</prgn> and <prgn>mktemp</prgn> utilities
- for use by scripts for this purpose.</p></sect>
+ The Debian base system provides the <prgn>tempfile</prgn>
+ and <prgn>mktemp</prgn> utilities for use by scripts for
+ this purpose.</p></sect>
<sect>
<p>
In order to ensure that local changes are preserved
correctly, no package may contain or make hard links to
- conffiles.
- <footnote>
+ conffiles.<footnote>
<p>
Rationale: There are two problems with hard links.
The first is that some editors break the link while
<tt>/usr/share/doc/<var>package</var>/examples</tt> if
they are examples, and should be perfectly ordinary
<prgn>dpkg</prgn>-handled files (<em>not</em>
- <tt>conffiles</tt>).
+ configuration files).
</p>
<p>
<tt>conffile</tt> must be tagged as <em>conflicting</em>
with each other. (This is an instance of the general rule
about not sharing files. Note that neither alternatives
- nor diversions are likely to be appropriate in this case.)
+ nor diversions are likely to be appropriate in this case;
+ in particular, <prgn>dpkg</prgn> does not handle diverted
+ <tt>conffile</tt>s well.)
</p>
<p>
grow indefinitely; the best way to do this is to drop a log
rotation configuration file into the directory
<tt>/etc/logrotate.d</tt> and use the facilities provided by
- logrotate.
- <footnote>
+ logrotate.<footnote>
<p>
The traditional approach to log files has been to set up
<em>ad hoc</em> log rotation schemes using simple shell
reconfigure the package to correspond to their local
security policy by changing the permissions on a binary:
they can do this by using <prgn>dpkg-statoverride</prgn>, as
- described below.
- <footnote>
+ described below.<footnote>
<p>
Ordinary files installed by <prgn>dpkg</prgn> (as
opposed to <tt>conffile</tt>s and other similar objects)
<p>
If a program needs to specify an <em>architecture specification
- string</em> in some place, the following format should be used:
- <example compact="compact">
-<var>arch</var>-<var>os</var>
- </example>
- where <tt><var>arch</var></tt> is one of the following:
- <tt>i386</tt>, <tt>alpha</tt>, <tt>arm</tt>, <tt>m68k</tt>,
- <tt>powerpc</tt>, <tt>sparc</tt> and <tt><var>os</var></tt>
- is one of: <tt>linux</tt>, <tt>gnu</tt>. Use of
- <tt>gnu</tt> in this string is reserved for the GNU/Hurd
- operating system.
+ string</em> in some place, the following format should be
+ used: <var>arch</var>-<var>os</var><footnote>
+ <p>
+ The following architectures and operating systems are
+ currently recognised by <prgn>dpkg-archictecture</prgn>.
+ The architecture, <tt><var>arch</var></tt>, is one of
+ the following: <tt>alpha</tt>, <tt>arm</tt>,
+ <tt>hppa</tt>, <tt>i386</tt>, <tt>ia64</tt>,
+ <tt>m68k</tt>, <tt>mips</tt>, <tt>mipsel</tt>,
+ <tt>powerpc</tt>, <tt>s390</tt>, <tt>sh</tt>,
+ <tt>sheb</tt>, <tt>sparc</tt> and <tt>sparc64</tt>. The
+ operating system, <tt><var>os</var></tt>, is one of:
+ <tt>linux</tt>, <tt>gnu</tt>, <tt>freebsd</tt> and
+ <tt>openbsd</tt>. Use of <tt>gnu</tt> in this string is
+ reserved for the GNU/Hurd operating system.
+ </p>
+ </footnote>.
</p>
<p>
- Note, that we don't want to use
+ Note that we don't want to use
<tt><var>arch</var>-debian-linux</tt> to apply to the rule
- `architecture-vendor-os' since this would make our programs
- incompatible with other Linux distributions. Also note that
- we don't use <tt><var>arch</var>-unknown-linux</tt>, since
- the <tt>unknown</tt> does not look very good.
+ <tt><var>architecture</var>-<var>vendor</var>-<var>os</var></tt>
+ since this would make our programs incompatible with other
+ Linux distributions. We also don't use something like
+ <tt><var>arch</var>-unknown-linux</tt>, since the
+ <tt>unknown</tt> does not look very good.
</p>
</sect>
<p>
The configuration files <tt>/etc/services</tt>,
<tt>/etc/protocols</tt>, and <tt>/etc/rpc</tt> are managed
- by the <prgn>netbase</prgn> package and may not be modified
- by other packages.</p>
+ by the <prgn>netbase</prgn> package and must not be modified
+ by other packages.
+ </p>
<p>
If a package requires a new entry in one of these files, the
maintainer should get in contact with the
<prgn>netbase</prgn> maintainer, who will add the entries
and release a new version of the <prgn>netbase</prgn>
- package.</p>
+ package.
+ </p>
<p>
The configuration file <tt>/etc/inetd.conf</tt> must not be
modified by the package's scripts except via the
<prgn>update-inetd</prgn> script or the
- <prgn>DebianNet.pm</prgn> Perl module.</p>
+ <tt>DebianNet.pm</tt> Perl module. See their documentation
+ for details on how to add entries.
+ </p>
<p>
If a package wants to install an example entry into
exactly one hash character (<tt>#</tt>). Such lines are
treated as `commented out by user' by the
<prgn>update-inetd</prgn> script and are not changed or
- activated during a package updates.</p></sect>
-
+ activated during package updates.
+ </p>
+ </sect>
<sect>
- <heading>Using pseudo-ttys and modifying wtmp, utmp and lastlog</heading>
+ <heading>Using pseudo-ttys and modifying wtmp, utmp and
+ lastlog</heading>
<p>
Some programs need to create pseudo-ttys. This should be done
<p>
The files <tt>/var/run/utmp</tt>, <tt>/var/log/wtmp</tt> and
<tt>/var/log/lastlog</tt> must be installed writeable by
- group utmp. Programs who need to modify those files must
- be installed setgid utmp.
+ group <tt>utmp</tt>. Programs which need to modify those
+ files must be installed setgid <tt>utmp</tt>.
</p>
</sect>
<p>
Some programs have the ability to launch an editor or pager
- program to edit or display a text document. Since there are
+ program to edit or display a text document. Since there are
lots of different editors and pagers available in the Debian
distribution, the system administrator and each user should
have the possibility to choose his/her preferred editor and
- pager.</p>
+ pager.
+ </p>
<p>
In addition, every program should choose a good default
editor/pager if none is selected by the user or system
- administrator.</p>
+ administrator.
+ </p>
<p>
Thus, every program that launches an editor or pager must
- use the EDITOR or PAGER environment variables to determine
- the editor/pager the user wants to get started. If these
+ use the EDITOR or PAGER environment variable to determine
+ the editor or pager the user wishes to use. If these
variables are not set, the programs <tt>/usr/bin/editor</tt>
- and <tt>/usr/bin/pager</tt> should be used, respectively.</p>
+ and <tt>/usr/bin/pager</tt> should be used, respectively.
+ </p>
<p>
- These two files are managed through `alternatives.' That is,
- every package providing an editor or pager must call the
+ These two files are managed through the <prgn>dpkg</prgn>
+ `alternatives' mechanism. Thus every package providing an
+ editor or pager must call the
<prgn>update-alternatives</prgn> script to register these
- programs.</p>
+ programs.
+ </p>
<p>
- If it is very hard to adapt a program to make us of the
- EDITOR and PAGER variables, that program may be configured
- to use <tt>/usr/bin/sensible-editor</tt> and
- <tt>/usr/bin/sensible-pager</tt> as editor or pager program,
- respectively. These are two scripts provided in the Debian
- base system that check the EDITOR and PAGER variables and
- launch the appropriate program or fall back to
- <tt>/usr/bin/editor</tt> and <tt>/usr/bin/pager</tt>,
- automatically.</p>
+ If it is very hard to adapt a program to make use of the
+ EDITOR or PAGER variables, that program may be configured to
+ use <tt>/usr/bin/sensible-editor</tt> and
+ <tt>/usr/bin/sensible-pager</tt> 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
+ <tt>/usr/bin/editor</tt> and <tt>/usr/bin/pager</tt> if the
+ variable is not set.
+ </p>
<p>
A program may also use the VISUAL environment variable to
- determine the user's choice of editor. If it exists, it
- should take precedence over EDITOR. This is in fact what
- <tt>/usr/bin/sensible-editor</tt> does.</p>
+ determine the user's choice of editor. If it exists, it
+ should take precedence over EDITOR. This is in fact what
+ <tt>/usr/bin/sensible-editor</tt> does.
+ </p>
<p>
It is not required for a package to depend on
- `editor' and `pager', nor is it required for a package to
- provide such virtual packages.
- <footnote>
+ <tt>editor</tt> and <tt>pager</tt>, nor is it required for a
+ package to provide such virtual packages.<footnote>
<p>
- The Debian base system already provides an editor and
- a pager program,
+ The Debian base system already provides an editor and a
+ pager program,
</p>
</footnote>
</p>
-
</sect>
-
<sect id="web-appl">
<heading>Web servers and applications</heading>
<p>
This section describes the locations and URLs that should
- be used by all web servers and web application in the Debian
- system.</p>
+ be used by all web servers and web applications in the
+ Debian system.
+ </p>
<p>
<enumlist>
<item>
- <p>Cgi-bin executable files are installed in the
+ <p>
+ Cgi-bin executable files are installed in the
directory
<example compact="compact">
/usr/lib/cgi-bin/<var>cgi-bin-name</var>
</p>
</item>
- <item><p>Access to html documents</p>
+ <item><p>Access to HTML documents</p>
<p>
- Html documents for a package are stored in
+ HTML documents for a package are stored in
<tt>/usr/share/doc/<var>package</var></tt> but should
be accessed via symlinks as
- <tt>/usr/doc/<var>package</var></tt><footnote> for
- backward compatibility, see <ref id="usrdoc"></footnote>
+ <tt>/usr/doc/<var>package</var></tt><footnote>
+ <p>
+ for backward compatibility; see <ref
+ id="usrdoc">
+ </p>
+ </footnote>
and can be referred to as
<example compact="compact">
http://localhost/doc/<var>package</var>/<var>filename</var>
the Web Document Root. Instead they should use the
/usr/share/doc/<var>package</var> directory for
documents and register the Web Application via the
- menu package. If access to the web-root is unavoidable
- then use
+ menu package. If access to the web document root is
+ unavoidable then use
<example compact="compact">
/var/www
</example>
- as the Document Root. This might be just a
- symbolic link to the location where the sysadmin has
- put the real document root.</p>
+ as the Document Root. This might be just a symbolic
+ link to the location where the system administrator
+ has put the real document root.
+ </p>
</item>
</enumlist></p></sect>
<heading>Mail transport, delivery and user agents</heading>
<p>
- Debian packages which process electronic mail, whether
- mail-user-agents (MUAs) or mail-transport-agents (MTAs),
- must make sure that they are compatible with the
- configuration decisions below. Failure to do this may
- result in lost mail, broken <tt>From:</tt> lines, and other
- serious brain damage!</p>
+ Debian packages which process electronic mail, whether mail
+ user agents (MUAs) or mail transport agents (MTAs), must
+ ensure that they are compatible with the configuration
+ decisions below. Failure to do this may result in lost
+ mail, broken <tt>From:</tt> lines, and other serious brain
+ damage!
+ </p>
<p>
- The mail spool is <tt>/var/mail</tt> and the interface
- to send a mail message is <tt>/usr/sbin/sendmail</tt> (as
- per the FHS). On older systems, the mail spool may be
- physically located in /var/spool/mail, but all access to the
- mail spool should be via the /var/mail symlink. The mail
- spool is part of the base system and not part of the MTA
- package.
- </p>
+ The mail spool is <tt>/var/mail</tt> and the interface to
+ send a mail message is <tt>/usr/sbin/sendmail</tt> (as per
+ the FHS). On older systems, the mail spool may be
+ physically located in <tt>/var/spool/mail</tt>, but all
+ access to the mail spool should be via the
+ <tt>/var/mail</tt> symlink. The mail spool is part of the
+ base system and not part of the MTA package.
+ </p>
<p>
All Debian MUAs, MTAs, MDAs and other mailbox accessing
- programs (like IMAP daemons) must lock the mailbox in an
+ programs (such as IMAP daemons) must lock the mailbox in an
NFS-safe way. This means that <tt>fcntl()</tt> locking must
- be combined with dot locking. To avoid deadlocks, a
- program should use <tt>fcntl()</tt> first and dot locking
- after this or alternatively implement the two locking
- methods in a non blocking way<footnote>
+ be combined with dot locking. To avoid deadlocks, a program
+ should use <tt>fcntl()</tt> first and dot locking after
+ this, or alternatively implement the two locking methods in
+ a non blocking way<footnote>
<p>
If it is not possible to establish both locks, the
system shouldn't wait for the second lock to be
established, but remove the first lock, wait a (random)
- time, and start over locking again.</p>
+ time, and start over locking again.
+ </p>
</footnote>. Using the functions <tt>maillock</tt> and
<tt>mailunlock</tt> provided by the
<tt>liblockfile*</tt><footnote>
<p>
- <tt>liblockfile</tt> version >>1.01</p>
+ You will need to depend on <tt>liblockfile1
+ (>>1.01)</tt> to use these functions.
+ </p>
</footnote> packages is the recommended way to realize this.
</p>
<p>
- Mailboxes are generally 660 <tt><var>user</var>.mail</tt>
- unless the user has chosen otherwise. A MUA may remove a
+ 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.</p>
+ Mailboxes must be writable by group mail.
+ </p>
<p>
The mail spool is 2775 <tt>root.mail</tt>, and MUAs should
<p>
<tt>/etc/aliases</tt> is the source file for the system mail
aliases (e.g., postmaster, usenet, etc.), it is the one
- which the sysadmin and <prgn>postinst</prgn> scripts may edit.
- After <tt>/etc/aliases</tt> is edited the program or human
- editing it must call <prgn>newaliases</prgn>. All MTA
+ which the sysadmin and <prgn>postinst</prgn> scripts may
+ edit. After <tt>/etc/aliases</tt> is edited the program or
+
human editing it must call <prgn>newaliases</prgn>. All MTA
packages must come with a <prgn>newaliases</prgn> program,
- even if it does nothing, but older MTA packages do not do
+ even if it does nothing, but older MTA packages did not do
this so programs should not fail if <prgn>newaliases</prgn>
- cannot be found.</p>
+ cannot be found. Note that because of this, all MTA
+ packages must have <tt>Provides</tt>, <tt>Conflicts</tt> and
+ <tt>Replaces: mail-transport-agent</tt> control file
+ fields.
+ </p>
<p>
The convention of writing <tt>forward to
is supported.</p>
<p>
- If you need to know what name to use (for example) on
- outgoing news and mail messages which are generated locally,
- you should use the file <tt>/etc/mailname</tt>. It will
- contain the portion after the username and <tt>@</tt> (at)
- sign for email addresses of users on the machine (followed
- by a newline).</p>
+ If your package needs to know what hostname to use on (for
+ example) outgoing news and mail messages which are generated
+ locally, you should use the file <tt>/etc/mailname</tt>. It
+ will contain the portion after the username and <tt>@</tt>
+ (at) sign for email addresses of users on the machine
+ (followed by a newline).
+ </p>
<p>
- A package should check for the existence of this file. If
- it exists it should use it without comment. (An MTA's
- prompting configuration script may wish to prompt the user
- even if it finds this file exists.) If it does not exist it
- should prompt the user for the value and store it in
- <tt>/etc/mailname</tt> as well as using it in the package's
- configuration. The prompt should make it clear that the
- name will not just be used by that package. For example, in
- this situation the INN package says:
+ Such package should check for the existence of this file
+ when it is being configured. If it exists, it should be
+ used without comment, although an MTA's configuration script
+ may wish to prompt the user even if it finds that this file
+ exists. If the file does not exist, the package should
+ prompt the user for the value (preferably using
+ <prgn>debconf</prgn>) and store it in <tt>/etc/mailname</tt>
+ as well as using it in the package's configuration. The
+ prompt should make it clear that the name will not just be
+ used by that package. For example, in this situation the
+ <tt>inn</tt> package could say something like:
<example compact="compact">
Please enter the `mail name' of your system. This is the
hostname portion of the address to be shown on outgoing
are:
<taglist>
- <tag>/etc/news/organization</tag>
+ <tag><tt>/etc/news/organization</tt></tag>
<item><p>A string which should appear as the
organization header for all messages posted
by NNTP clients on the machine</p></item>
- <tag>/etc/news/server</tag>
+ <tag><tt>/etc/news/server</tt></tag>
<item><p>Contains the FQDN of the upstream NNTP
server, or localhost if the local machine is
an NNTP server.</p></item>
<sect>
<heading>Programs for the X Window System</heading>
- <p>
- <em>Programs that may be configured with support for the X Window
- System</em> must be configured to do so and must declare any
- package dependencies necessary to satisfy their runtime
- requirements when using the X Window System, unless the package
- in question is of standard or higher priority, in which case
- X-specific binaries may be split into a separate package, or
- alternative versions of the package with X support may be
- provided.
- </p>
+ <sect1>
+ <heading>Providing X support and package priorities</heading>
+
+ <p>
+ Programs that can be configured with support for the X
+ Window System must be configured to do so and must declare
+ any package dependencies necessary to satisfy their
+ runtime requirements when using the X Window System. If
+ such a package is of higher priority than the X packages
+ on which it depends, it is required that either the
+ X-specific components be split into a separate package, or
+ that an alternative version of the package, which includes
+ X support, be provided, or that the package's priority be
+ lowered.
+ </p>
+ </sect1>
+ <sect1>
+ <heading>Packages providing an X server</heading>
- <p>
- <em>Packages which provide an X server</em> that, directly or
- indirectly, communicates with real input and display hardware
- should declare in their control data that they provide the
- virtual package <tt>xserver</tt>.
- <footnote>
- <p>
- This implements current practice, and provides an actual
- policy for usage of the "xserver" virtual package which
- appears in the virtual packages list. In a nutshell, X
- servers that interface directly with the display and input
- hardware or via another subsystem (e.g., GGI) should provide
- xserver. Things like Xvfb, Xnest, and Xprt should not.
- </p>
- </footnote>
- </p>
+ <p>
+ Packages that provide an X server that, directly or
+ indirectly, communicates with real input and display
+ hardware should declare in their control data that they
+ provide the virtual package <tt>xserver</tt>.<footnote>
+ <p>
+ This implements current practice, and provides an
+ actual policy for usage of the <tt>xserver</tt>
+ virtual package which appears in the virtual packages
+ list. In a nutshell, X servers that interface
+ directly with the display and input hardware or via
+ another subsystem (e.g., GGI) should provide
+ <tt>xserver</tt>. Things like <tt>Xvfb</tt>,
+ <tt>Xnest</tt>, and <tt>Xprt</tt> should not.
+ </p>
+ </footnote>
+ </p>
+ </sect1>
- <p>
- <em>Packages that provide a terminal emulator</em> for the X
- Window System which support a terminal type with a terminfo
- description provided in the <tt>ncurses-base</tt> package
- should declare in their control data that they provide the
- virtual package <tt>x-terminal-emulator</tt>. They should
- also register themselves as an alternative for
- <tt>/usr/bin/x-terminal-emulator</tt>, with a priority of
- 20.
- </p>
+ <sect1>
+ <heading>Packages providing a terminal emulator</heading>
- <p>
- <em>Packages that provide window managers</em> should declare in
- their control data that they provide the virtual package
- <tt>x-window-manager</tt>. They should also register themselves as an
- alternative for <tt>/usr/bin/x-window-manager</tt>, with a priority
- calculated as follows:
- <list compact="compact">
- <item>Start with a priority of 20.</item>
- <item>If the window manager supports the Debian menu system,
- add 20 points if this support is available in the
- package's default configuration (i.e., no
- configuration files belonging to the system or user
- have to be edited to activate the feature); if
- configuration files must be modified, add only 10
- points.</item>
- <item>If the window manager permits the X session to be
- restarted using a <em>different</em> window manager
- (without killing the X server) in its default
- configuration, add 10 points; otherwise add
- none.</item>
- </list>
- </p>
+ <p>
+ Packages that provide a terminal emulator for the X Window
+ System which meet the criteria listed below should declare
+ in their control data that they provide the virtual
+ package <tt>x-terminal-emulator</tt>. They should also
+ register themselves as an alternative for
+ <tt>/usr/bin/x-terminal-emulator</tt>, with a priority of
+ 20.
+ </p>
- <p>
- <em>Packages that provide fonts for the X Window System</em>
- must do a number of things to ensure that they are both
- available without modification of the X or font server
- configuration, and that they do not corrupt files used by
- other font packages to register information about themselves.
- <enumlist>
- <item>
- Fonts of any type supported by the X Window System
- should be be in a separate binary package from any
- executables, libraries, or documentation (except that
- specific to the fonts shipped); if a program or
- library is <em>unusable</em> without one or more
- specific fonts, the package containing the program or
- library should declare a dependency on the package(s)
- containing the font(s) it requires.
- </item>
- <item>
- BDF fonts should be converted to PCF fonts with the
- <tt>bdftopcf</tt> utility (available in the
- <tt>xutils</tt> package), <tt>gzip</tt>ped, and
- placed in a directory that corresponds to their
- resolution:
- <list compact="compact">
- <item>
- 100 dpi fonts should be placed in
- <tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>.
- </item>
- <item>
- 75 dpi fonts should be placed in
- <tt>/usr/X11R6/lib/X11/fonts/75dpi/</tt>.
- </item>
- <item>
- Character-cell fonts, cursor fonts, and other
- low-resolution fonts should be placed in
- <tt>/usr/X11R6/lib/X11/fonts/misc/</tt>.
- </item>
- </list>
- </item>
- <item>
- Speedo fonts should be placed in
- <tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt>.
- </item>
- <item>
- Type 1 fonts should be placed in
- <tt>/usr/X11R6/lib/X11/fonts/Type1/</tt>. If font
- metric files are available, they may be placed here as
- well.
- </item>
- <item>
- Subdirectories of <tt>/usr/X11R6/lib/X11/fonts/</tt>
- other than those listed above should be neither created nor
- used. (The <tt>PEX</tt> and <tt>cyrillic</tt> directories are
- excepted for historical reasons, but installation of files into
- these directories remains discouraged.)
- </item>
- <item>
- Font packages may, instead of placing files directly in
- the X font directories listed above, provide symbolic links in
- the font directory which point to the files' actual location
- in the filesystem. Such a location should comply with the
- FHS.
- </item>
- <item>
- Font packages should not contain both 75dpi and 100dpi
- versions of a font. If both are available, they should be
- provided in separate binary packages with "-75dpi" or "-100dpi"
- appended to the names of the packages containing the
- corresponding fonts.
- </item>
- <item>
- Fonts destined for the <tt>misc</tt> subdirectory should
- not be included in the same package as 75dpi or 100dpi fonts;
- instead, they should be provided in a separate package with
- "-misc" appended to its name.
- </item>
- <item>
- Font packages <em>must not</em> provide the files
- <tt>fonts.dir</tt>, <tt>fonts.alias</tt>, or
- <tt>fonts.scale</tt> in a font directory.
- <list compact="compact">
- <item>
- <tt>fonts.dir</tt> files must not be provided at
- all.
- </item>
- <item>
- <tt>fonts.alias</tt> and <tt>fonts.scale</tt>
- files, if needed, should be provided in the
- directory
- <tt>/etc/X11/fonts/<em>fontdir</em>/<em>package</em>.<em>extension</em></tt>,
- where <em>fontdir</em> is the name of the
- subdirectory of
- <tt>/usr/X11R6/lib/X11/fonts/</tt> where the
- package's corresponding fonts are stored (e.g.,
- <tt>75dpi</tt> or <tt>misc</tt>),
- <em>package</em> is the name of the package that
- provides these fonts, and <em>extension</em> is
- either <tt>scale</tt> or <tt>alias</tt>,
- whichever corresponds to the file
- contents.
- </item>
- </list>
- </item>
- <item>
- Font packages must declare a dependency on
- <tt>xutils</tt> and, in the package
- post-installation and post-removal scripts, invoke the
- <tt>mkfontdir</tt> command on each directory into
- which they installed fonts.
- </item>
- <item>
- Font packages that provide one or more
- <tt>fonts.scale</tt> files as described above must declare a
- versioned dependency on <tt>xutils (>=
- 4.0.2)</tt> and invoke <tt>update-fonts-scale</tt> on each
- directory into which they installed fonts
- <em>before</em> invoking <tt>mkfontdir</tt> on that
- directory. This invocation must occur in both the
- post-installation and post-removal scripts.
- </item>
- <item>
- Font packages that provide one or more
- <tt>fonts.alias</tt> files as described above must
- declare a versioned dependency on <tt>xutils
- (>= 4.0.2)</tt> and, in the package
- post-installation and post-removal scripts, invoke
- <tt>update-fonts-alias</tt> on each directory into
- which they installed fonts.
- </item>
- <item>
- Font packages must not provide alias names for the
- fonts they include which collide with alias names already in
- use by fonts already packaged.
- </item>
- <item>
- Font packages must not provide fonts with the same XLFD
- registry name as another font already packaged.
- </item>
- </enumlist>
- </p>
+ <p>
+ To be an <tt>x-terminal-emulator</tt>, a program must:
+ <list compact="compact">
+ <item><p>
+ Be able to emulate a DEC VT100 terminal, or a
+ compatible terminal.
+ </p></item>
+
+ <item><p>
+ Support the command-line option <tt>-e
+ <var>command</var></tt>, which creates a new
+ terminal window<footnote>
+ <p>
+ "New terminal window" does not necessarily mean
+ a new top-level X window directly parented by
+ the window manager; it could, if the terminal
+ emulator application were so coded, be a new
+ "view" in a multiple-document interface (MDI).
+ </p>
+ </footnote>
+ and runs the specified <var>command</var>.
+ </p></item>
+
+ <item><p>
+ Support the command-line option <tt>-T
+ <var>title</var></tt>, which creates a new terminal
+ window with the window title <var>title</var>.
+ </p></item>
+ </list>
+ </p>
+ </sect1>
- <p>
- <em>Application defaults</em> files must be installed in the
- directory <tt>/etc/X11/app-defaults/</tt> (use of a
- localized subdirectory of <tt>/etc/X11/</tt> as described in
- the <em>X Toolkit Intrinsics - C Language Interface</em>
- manual is also permitted). They must be registered as
- <em>conffile</em>s or handled as configuration files. For
- programs that are not linked against the X Toolkit (Xt)
- library, customization of programs' X resources may also be
- supported with the provision of a file with the same name as
- that of the package placed in the
- <tt>/etc/X11/Xresources/</tt> directory, which must
- registered as a <em>conffile</em> or handled as a
- configuration file. <em>Important:</em> packages that
- install files into the <tt>/etc/X11/Xresources/</tt>
- directory <em>must</em> declare a conflict with <tt>xbase
- (<< 3.3.2.3a-2)</tt>; if this is not done it is
- possible for the installing package to destroy a
- previously-existing <tt>/etc/X11/Xresources</tt> file which
- had been customized by the system administrator.
- </p>
-
- <p>
- <em>Packages using the X Window System should abide by the
- FHS standard whenever possible</em>; they should install
- binaries, libraries, manual pages, and other files in
- FHS-mandated locations wherever possible. This means that
- files must not be installed into <tt>/usr/X11R6/bin/</tt>,
- <tt>/usr/X11R6/lib/</tt>, or <tt>/usr/X11R6/man/</tt>
- unless this is necessary for the package to operate
- properly. Configuration files for window managers and
- display managers should be placed in a subdirectory of
- <tt>/etc/X11/</tt> corresponding to the package name due
- to these programs' tight integration with the mechanisms
- of the X Window System. Application-level programs should
- use the <tt>/etc/</tt> directory unless otherwise mandated
- by policy. The installation of files into subdirectories
- of <tt>/usr/X11R6/include/X11/</tt> and
- <tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
- package maintainers should determine if subdirectories of
- <tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
- instead (symlinks from the X11R6 directories to
- FHS-compliant locations is encouraged if the program is
- not easily configured to look elsewhere for its files).
- Packages must not provide or install files into the
- directories <tt>/usr/bin/X11/</tt>,
- <tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>.
- Files within a package should, however, make reference to
- these directories, rather than their X11R6-named
- counterparts <tt>/usr/X11R6/bin/</tt>,
- <tt>/usr/X11R6/include/X11/</tt>, and
- <tt>/usr/X11R6/lib/X11/</tt>, if the resources being
- referred to have not been moved to FHS-compliant
- locations.
- </p>
+ <sect1>
+ <heading>Packages providing a window manager</heading>
- <p>
- <em>Programs that require the non-DFSG-compliant OSF/Motif
- library</em> should be compiled against and tested with
- LessTif (a free re-implementation of Motif) instead. If the
- maintainer judges that the program or programs do not work
- sufficiently well with LessTif to be distributed and
- supported, but do so when compiled against Motif, then two
- versions of the package should be created; one linked
- statically against Motif and with <tt>-smotif</tt> appended
- to the package name, and one linked dynamically against
- Motif and with <tt>-dmotif</tt> appended to the package
- name. Both Motif-linked versions are dependent upon
- non-DFSG-compliant software and thus cannot be uploaded to
- the main distribution; if the software is itself
- DFSG-compliant it may be uploaded to the contrib
- distribution. While known existing versions of OSF/Motif
- permit unlimited redistribution of binaries linked against
- the library (whether statically or dynamically), it is the
- package maintainer's responsibility to determine whether
- this is permitted by the license of the copy of OSF/Motif in
- his or her possession.
- </p>
- </sect>
+ <p>
+ Packages that provide a window manager should declare in
+ their control data that they provide the virtual package
+ <tt>x-window-manager</tt>. They should also register
+ themselves as an alternative for
+ <tt>/usr/bin/x-window-manager</tt>, with a priority
+ calculated as follows:
+ <list compact="compact">
+ <item><p>Start with a priority of 20.</p></item>
- <sect>
- <heading>Perl programs and modules</heading>
- <p>
- Perl programs and modules should follow the current Perl
- policy as defined in the file found on
- <ftpsite>ftp.debian.org</ftpsite> in
- <ftppath>/debian/doc/package-developer/perl-policy.txt.gz</ftppath>
- or your local mirror. In addition, it is included in the
- <tt>debian-policy</tt> package.
- </p>
- </sect>
+ <item>
+ <p>
+ If the window manager supports the Debian menu
+ system, add 20 points if this support is available
+ in the package's default configuration (i.e., no
+ configuration files belonging to the system or user
+ have to be edited to activate the feature); if
+ configuration files must be modified, add only 10
+ points.
+ </p>
+ </item>
- <sect>
- <heading>Emacs lisp programs</heading>
+ <item>
+ <p>
+ If the window manager permits the X session to be
+ restarted using a <em>different</em> window manager
+ (without killing the X server) in its default
+ configuration, add 10 points; otherwise add none.
+ </p>
+ </item>
+ </list>
+ </p>
+ </sect1>
- <p>
- Please refer to the `Debian Emacs Policy' (documented in
- <tt>debian-emacs-policy.gz</tt> of the
- <prgn>emacsen-common</prgn> package) for details of how to
- package emacs lisp programs.</p></sect>
+ <sect1>
+ <heading>Packages providing fonts</heading>
+ <p>
+ Packages that provide fonts for the X Window
+ System<footnote>
+ <p>
+ For the purposes of Debian Policy, a "font for the X
+ Window System" is one which is accessed via X protocol
+ requests. Fonts for the Linux console, for PostScript
+ renderers, or any other purpose, do not fit this
+ definition. Any tool which makes such fonts available
+ to the X Window System, however, must abide by this
+ font policy.
+ </p>
+ </footnote>
+ must do a number of things to ensure that they are both
+ available without modification of the X or font server
+ configuration, and that they do not corrupt files used by
+ other font packages to register information about
+ themselves.
+ <enumlist>
+ <item>
+ <p>
+ Fonts of any type supported by the X Window System
+ must be be in a separate binary package from any
+ executables, libraries, or documentation (except
+ that specific to the fonts shipped, such as their
+ license information). If one or more of the fonts
+ so packaged are necessary for proper operation of
+ the package with which they are associated the font
+ package may be Recommended; if the fonts merely
+ provide an enhancement, a Suggests relationship may
+ be used. Packages must not Depend on font
+ packages.<footnote>
+ <p>
+ This is because the X server may retrieve fonts
+ from the local filesystem or over the network
+ from an X font server; the Debian package system
+ is empowered to deal only with the local
+ filesystem.
+ </p>
+ </footnote>
+ </p>
+ </item>
- <sect>
- <heading>Games</heading>
+ <item>
+ <p>
+ BDF fonts must be converted to PCF fonts with the
+ <prgn>bdftopcf</prgn> utility (available in the
+ <tt>xutils</tt> package, <tt>gzip</tt>ped, and
+ placed in a directory that corresponds to their
+ resolution:
+ <list compact="compact">
+ <item><p>
+ 100 dpi fonts must be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>.
+ </p></item>
+
+ <item><p>
+ 75 dpi fonts must be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/75dpi/</tt>.
+ </p></item>
+
+ <item><p>
+ Character-cell fonts, cursor fonts, and other
+ low-resolution fonts must be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/misc/</tt>.
+ </p></item>
+ </list>
+ </p>
+ </item>
- <p>
- The permissions on /var/games are 755
- <tt>root.root</tt>.</p>
+ <item><p>
+ Speedo fonts must be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt>.
+ </p></item>
- <p>
- Each game decides on its own security policy.</p>
+ <item><p>
+ Type 1 fonts must be placed in
+ <tt>/usr/X11R6/lib/X11/fonts/Type1/</tt>. If font
+ metric files are available, they must be placed here
+ as well.
+ </p></item>
- <p>
- Games which require protected, privileged access to
- high-score files, savegames, etc., may be made
- set-<em>group</em>-id (mode 2755) and owned by
- <tt>root.games</tt>, and use files and directories with
- appropriate permissions (770 <tt>root.games</tt>, for
- example). They must not be made
- set-<em>user</em>-id, as this causes security problems. (If
+ <item>
+ <p>
+ Subdirectories of <tt>/usr/X11R6/lib/X11/fonts/</tt>
+ other than those listed above must be neither
+ created nor used. (The <tt>PEX</tt>, <tt>CID</tt>,
+ and <tt>cyrillic</tt> directories are excepted for
+ historical reasons, but installation of files into
+ these directories remains discouraged.)
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages may, instead of placing files directly
+ in the X font directories listed above, provide
+ symbolic links in the font directory which point to
+ the files' actual location in the filesystem. Such
+ a location must comply with the FHS.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages should not contain both 75dpi and
+ 100dpi versions of a font. If both are available,
+ they should be provided in separate binary packages
+ with <tt>-75dpi</tt> or <tt>-100dpi</tt> appended to
+ the names of the packages containing the
+ corresponding fonts.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Fonts destined for the <tt>misc</tt> subdirectory
+ should not be included in the same package as 75dpi
+ or 100dpi fonts; instead, they should be provided in
+ a separate package with <tt>-misc</tt> appended to
+ its name.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages must not provide the files
+ <tt>fonts.dir</tt>, <tt>fonts.alias</tt>, or
+ <tt>fonts.scale</tt> in a font directory:
+ <list>
+ <item><p>
+ <tt>fonts.dir</tt> files must not be provided at all.
+ </p></item>
+
+ <item>
+ <p>
+ <tt>fonts.alias</tt> and <tt>fonts.scale</tt>
+ files, if needed, should be provided in the
+ directory
+ <tt>/etc/X11/fonts/<var>fontdir</var>/<var>package</var>.<var>extension</var></tt>,
+ where <var>fontdir</var> is the name of the
+ subdirectory of
+ <tt>/usr/X11R6/lib/X11/fonts/</tt> where the
+ package's corresponding fonts are stored
+ (e.g., <tt>75dpi</tt> or <tt>misc</tt>),
+ <var>package</var> is the name of the package
+ that provides these fonts, and
+ <var>extension</var> is either <tt>scale</tt>
+ or <tt>alias</tt>, whichever corresponds to
+ the file contents.
+ </p>
+ </item>
+ </list>
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages must declare a dependency on
+ <tt>xutils (>> 4.0.3)</tt> in their control
+ data.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages that provide one or more
+ <tt>fonts.scale</tt> files as described above must
+ invoke <prgn>update-fonts-scale</prgn> on each
+ directory into which they installed fonts
+ <em>before</em> invoking
+ <prgn>update-fonts-dir</prgn> on that directory.
+ This invocation must occur in both the
+ <prgn>postinst</prgn> (for all arguments) and
+ <prgn>postrm</prgn> (for all arguments except
+ <tt>upgrade</tt>) scripts.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages that provide one or more
+ <tt>fonts.alias</tt> files as described above must
+ invoke <prgn>update-fonts-alias</prgn> on each
+ directory into which they installed fonts. This
+ invocation must occur in both the
+ <prgn>postinst</prgn> (for all arguments) and
+ <prgn>postrm</prgn> (for all arguments except
+ <tt>upgrade</tt>) scripts.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages must invoke
+ <prgn>update-fonts-dir</prgn> on each directory into
+ which they installed fonts. This invocation must
+ occur in both the <prgn>postinst</prgn> (for all
+ arguments) and <prgn>postrm</prgn> (for all
+ arguments except <tt>upgrade</tt>) scripts.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages must not provide alias names for the
+ fonts they include which collide with alias names
+ already in use by fonts already packaged.
+ </p>
+ </item>
+
+ <item>
+ <p>
+ Font packages must not provide fonts with the same
+ XLFD registry name as another font already packaged.
+ </p>
+ </item>
+ </enumlist>
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>Application defaults files</heading>
+
+ <p>
+ Application defaults files must be installed in the
+ directory <tt>/etc/X11/app-defaults/</tt> (use of a
+ localized subdirectory of <tt>/etc/X11/</tt> as described
+ in the <em>X Toolkit Intrinsics - C Language
+ Interface</em> manual is also permitted). They must be
+ registered as <tt>conffile</tt>s or handled as
+ configuration files. Packages must not provide the
+ directory <tt>/usr/X11R6/lib/X11/app-defaults/</tt>.
+ </p>
+
+ <p>
+ Customization of programs' X resources may also be
+ supported with the provision of a file with the same name
+ as that of the package placed in the
+ <tt>/etc/X11/Xresources/</tt> directory, which must
+ registered as a <tt>conffile</tt> or handled as a
+ configuration file.<footnote>
+ <p>
+ Note that this mechanism is not the same as using
+ app-defaults; app-defaults are tied to the client
+ binary on the local filesystem, whereas X resources
+ are stored in the X server and affect all connecting
+ clients.
+ </p>
+ </footnote>
+ <em>Important:</em> packages that install files into the
+ <tt>/etc/X11/Xresources/</tt> directory must conflict with
+ <tt>xbase (<< 3.3.2.3a-2)</tt>; if this is not done
+ it is possible for the installing package to destroy a
+ previously-existing <tt>/etc/X11/Xresources</tt> file
+ which had been customized by the system administrator.
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>Installation directory issues</heading>
+
+ <p>
+ Packages using the X Window System should not be
+ configured to install files under the <tt>/usr/X11R6/</tt>
+ directory unless they use <prgn>imake</prgn>. The
+ <tt>/usr/X11R6/</tt> directory hierarchy should be
+ regarded as deprecated for all packages except the X
+ Window System itself, and those which use the
+ <prgn>imake</prgn> program it provides, in which case the
+ packages may transition out of the <tt>/usr/X11R6/</tt>
+ directory at the maintainer's discretion.<footnote>
+ <p>
+ <prgn>Imake</prgn>-using programs are exempt because,
+ as long as they are written correctly, the pathnames
+ they use to locate resources and install themselves
+ are derived wholly from the X Window System
+ configuration. Thus, in the event that the X Window
+ System moves to <tt>/usr/X11R7/</tt>,
+ <tt>/usr/X12/</tt>, or just plain <tt>/usr/</tt>, all
+ that is required for these programs is a recompile
+ against the corresponding X Window System library
+ development packages.
+ </p>
+ </footnote>
+ Programs that use GNU <prgn>autoconf</prgn> and
+ <prgn>automake</prgn> are usually easily configured at
+ compile time to use <tt>/usr/</tt> instead of
+ <tt>/usr/X11R6/</tt>, and this should be done whenever
+ possible. Configuration files for window managers and
+ display managers should be placed in a subdirectory of
+ <tt>/etc/X11/</tt> corresponding to the package name due
+ to these programs' tight integration with the mechanisms
+ of the X Window System. Application-level programs should
+ use the <tt>/etc/</tt> directory unless otherwise mandated
+ by policy. The installation of files into subdirectories
+ of <tt>/usr/X11R6/include/X11/</tt> and
+ <tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
+ package maintainers should determine if subdirectories of
+ <tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
+ instead. (The use of symbolic links from the
+ <tt>X11R6</tt> directories to other FHS-compliant
+ locations is encouraged if the program is not easily
+ configured to look elsewhere for its files.) Packages
+ must not provide or install files into the directories
+ <tt>/usr/bin/X11/</tt>, <tt>/usr/include/X11/</tt> or
+ <tt>/usr/lib/X11/</tt>. Files within a package should,
+ however, make reference to these directories, rather than
+ their <tt>X11R6</tt>-named counterparts
+ <tt>/usr/X11R6/bin/</tt>, <tt>/usr/X11R6/include/X11/</tt>
+ and <tt>/usr/X11R6/lib/X11/</tt>, if the resources being
+ referred to have not been moved to other FHS-compliant
+ locations.
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>The OSF/Motif and OpenMotif libraries</heading>
+
+ <p>
+ <em>Programs that require the non-DFSG-compliant OSF/Motif or
+ OpenMotif libraries</em><footnote>
+ <p>
+ OSF/Motif and OpenMotif are collectively referred to as
+ "Motif" in this policy document.
+ </p>
+ </footnote>
+ should be compiled against and tested with LessTif (a free
+ re-implementation of Motif) instead. If the maintainer
+ judges that the program or programs do not work
+ sufficiently well with LessTif to be distributed and
+ supported, but do so when compiled against Motif, then two
+ versions of the package should be created; one linked
+ statically against Motif and with <tt>-smotif</tt>
+ appended to the package name, and one linked dynamically
+ against Motif and with <tt>-dmotif</tt> appended to the
+ package name. Both Motif-linked versions are dependent
+ upon non-DFSG-compliant software and thus cannot be
+ uploaded to the <em>main</em> distribution; if the
+ software is itself DFSG-compliant it may be uploaded to
+ the <em>contrib</em> distribution. While known existing
+ versions of Motif permit unlimited redistribution of
+ binaries linked against the library (whether statically or
+ dynamically), it is the package maintainer's
+ responsibility to determine whether this is permitted by
+ the license of the copy of Motif in his or her possession.
+ </p>
+ </sect1>
+ </sect>
+
+ <sect>
+ <heading>Perl programs and modules</heading>
+ <p>
+ Perl programs and modules should follow the current Perl
+ policy as defined in the file found on
+ <ftpsite>ftp.debian.org</ftpsite> in
+ <ftppath>/debian/doc/package-developer/perl-policy.txt.gz</ftppath>
+ or your local mirror. In addition, it is included in the
+ <tt>debian-policy</tt> package.
+ </p>
+ </sect>
+
+ <sect>
+ <heading>Emacs lisp programs</heading>
+
+ <p>
+ Please refer to the `Debian Emacs Policy' (documented in
+ <tt>debian-emacs-policy.gz</tt> of the
+ <prgn>emacsen-common</prgn> package) for details of how to
+ package emacs lisp programs.
+ </p>
+ </sect>
+
+ <sect>
+ <heading>Games</heading>
+
+ <p>
+ The permissions on <tt>/var/games</tt> are mode 755, owner
+ <tt>root</tt> and group <tt>root</tt>.
+ </p>
+
+ <p>
+ Each game decides on its own security policy.</p>
+
+ <p>
+ Games which require protected, privileged access to
+ high-score files, savegames, etc., may be made
+ set-<em>group</em>-id (mode 2755) and owned by
+ <tt>root.games</tt>, and use files and directories with
+ appropriate permissions (770 <tt>root.games</tt>, for
+ example). They must not be made
+ set-<em>user</em>-id, as this causes security problems. (If
an attacker can subvert any set-user-id game they can
overwrite the executable of any other, causing other players
of these games to run a Trojan horse program. With a
<p>
If no manual page is available for a particular program,
- utility, function or configuration file and this is reported as a bug on
- debian-bugs, a symbolic link from the requested manual page
- to the <manref name="undocumented" section="7"> manual page
- may be provided. This symbolic link can be created from
+ utility, function or configuration file and this is reported
+ as a bug to the Debian Bug Tracking System, a symbolic link
+ from the requested manual page to the <manref
+ name="undocumented" section="7"> manual page may be
+ provided. This symbolic link can be created from
<tt>debian/rules</tt> like this:
<example compact="compact">
ln -s ../man7/undocumented.7.gz \
-debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz
+ debian/tmp/usr/share/man/man[1-9]/<var>requested_manpage</var>.[1-9].gz
</example>
This manpage claims that the lack of a manpage has been
reported as a bug, so you may only do this if it really has
is better to use a symbolic link than the <tt>.so</tt>
feature, but there is no need to fiddle with the relevant
parts of the upstream source to change from <tt>.so</tt> to
- symlinks: don't do it unless it's easy. You should not create hard
- links in the manual page directories, nor put
+ symlinks: don't do it unless it's easy. You should not
+ create hard links in the manual page directories, nor put
absolute filenames in <tt>.so</tt> directives. The filename
in a <tt>.so</tt> in a manpage should be relative to the
base of the manpage tree (usually
- <tt>/usr/share/man</tt>).</p></sect>
-
+ <tt>/usr/share/man</tt>). If you do not create any links
+ (whether symlinks, hard links, or <tt>.so</tt> directives)
+ in the filesystem to the alternate names of the manpage,
+ then you should not rely on <prgn>man</prgn> finding your
+ manpage under those names based solely on the information in
+ the manpage's header.<footnote>
+ <p>
+ Supporting this in <prgn>man</prgn> often requires
+ unreasonable processing time to find a manual page or to
+ report that none exists, and moves knowledge into man's
+ database that would be better left in the filesystem.
+ This support is therefore deprecated and will cease to
+ be present in the future.
+ </p>
+ </footnote>
+ </p>
+ </sect>
<sect>
<heading>Info documents</heading>
They should be compressed with <tt>gzip -9</tt>.</p>
<p>
- Your package should call <prgn>install-info</prgn> to update the Info
- <tt>dir</tt>
- file, in its post-installation script:
+ Your package should call <prgn>install-info</prgn> to update
+ the Info <tt>dir</tt> 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
+ /usr/share/info/foobar.info
</example></p>
<p>
the second is used when creating a new one.</p>
<p>
- You should remove the entries in the pre-removal script:
+ 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>
+ name="install-info" section="8"> for details.</p>
</sect>
<sect>
<p>
Any additional documentation that comes with the package may
be installed at the discretion of the package maintainer.
- Text documentation should be installed in a directory
+ Text documentation should be installed in the directory
<tt>/usr/share/doc/<var>package</var></tt>, where
<var>package</var> is the name of the package, and
compressed with <tt>gzip -9</tt> unless it is small.</p>
delete them without causing any programs to break. Any files
that are referenced by programs but are also useful as
standalone documentation should be installed under
- <tt>/usr/share/<var>package</var>/</tt> and symlinked in
- <tt>/usr/share/doc/<var>package</var>/</tt>.
+ <tt>/usr/share/<var>package</var>/</tt> with symbolic links
+ from <tt>/usr/share/doc/<var>package</var>/</tt>.
</p>
</sect>
it cannot be contained in the package itself due to problems
with <prgn>dpkg</prgn>. One reasonable way to accomplish
this is to put the following in the package's
- <prgn>postinst</prgn>:
+ <prgn>postinst</prgn><footnote>
+ <p>
+ The <tt>debhelper</tt> script
+ <prgn>dh_installdocs</prgn> does this automatically.
+ </p>
+ </footnote>:
<example compact="compact">
if [ "$1" = "configure" ]; then
- if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \
- -a -d /usr/share/doc/#PACKAGE# ]; then
- ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE#
+ if [ -d /usr/doc -a ! -e /usr/doc/<var>package</var> \
+ -a -d /usr/share/doc/<var>package</var> ]; then
+ ln -sf ../share/doc/<var>package</var> /usr/doc/<var>package</var>
fi
fi
</example>
-
And the following in the package's <prgn>prerm</prgn>:
+
and the following in the package's <prgn>prerm</prgn>:
<example compact="compact">
if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
- -a -L /usr/doc/#PACKAGE# ]; then
- rm -f /usr/doc/#PACKAGE#
+ -a -L /usr/doc/<var>package</var> ]; then
+ rm -f /usr/doc/<var>package</var>
fi
</example>
</p>
<p>
If your package comes with extensive documentation in a
- mark up format that can be converted to various other formats
+ markup format that can be converted to various other formats
you should if possible ship HTML versions in a binary
package, in the directory
- <tt>/usr/share/doc/<var>appropriate package</var></tt> or its
- subdirectories.
- <footnote>
- <p>The rationale: The important thing here is that HTML
+ <tt>/usr/share/doc/<var>appropriate-package</var></tt> or
+ its subdirectories.<footnote>
+ <p>
+ The rationale: The important thing here is that HTML
docs should be available in <em>some</em> package, not
- necessarily in the main binary package, though. </p>
+ necessarily in the main binary package.
+ </p>
</footnote>
</p>
<p>
- Other formats such as PostScript may be provided at your
- option.</p>
+ Other formats such as PostScript may be provided at the
+ package maintainer's discretion.
+ </p>
</sect>
<sect id="copyrightfile">
<p>
Every package must be accompanied by a verbatim copy of its
copyright and distribution license in the file
- /usr/share/doc/<var>package</var>/copyright. This file must
- neither be compressed nor be a symbolic link.</p>
+ <tt>/usr/share/doc/<var>package</var>/copyright</tt>. This
+ file must neither be compressed nor be a symbolic link.
+ </p>
<p>
In addition, the copyright file must say where the upstream
<p>
A copy of the file which will be installed in
- <tt>/usr/share/doc/<var>package</var>/copyright</tt> should be
- in <tt>debian/copyright</tt>.</p>
-
+ <tt>/usr/share/doc/<var>package</var>/copyright</tt> should
+ be in <tt>debian/copyright</tt> in the source package.
+ </p>
<p>
- /usr/share/doc/<var>package</var> may be a symbolic link to a
- directory in /usr/share/doc only if two packages both come from
- the same source and the first package has a "Depends"
- relationship on the second. These rules are important
- because copyrights must be extractable by mechanical
- means.</p>
+ <tt>/usr/share/doc/<var>package</var></tt> may be a symbolic
+ link to another directory in <tt>/usr/share/doc</tt> only if
+ the two packages both come from the same source and the
+ first package Depends on the second. These rules are
+ important because copyrights must be extractable by
+ mechanical means.
+ </p>
<p>
Packages distributed under the UCB BSD license, the Artistic
license, the GNU GPL, and the GNU LGPL should refer to the
- files /usr/share/common-licenses/BSD,
- /usr/share/common-licenses/Artistic,
- /usr/share/common-licenses/GPL, and
- /usr/share/common-licenses/LGPL.
- <footnote>
- <p>
- Why "licenses" and not "copyright"? Because
- <tt>/usr/doc/copyright</tt> used to contain all the
- copyright files, plus the four common licenses GPL,
- LGPL, Artistic and BSD. Now individual copyright files
- for packages are no longer in a common directory. Once
- <tt>/usr/doc/copyright</tt> is almost empty it makes
- sense to rename "copyright" to "licenses"
- </p>
- <p>
- Why "common-licenses" and not "licenses"? Because if I
- put just "licenses" I'm sure I will receive a bug report
- saying "license foo is not included in the licenses
- directory. They are not all the licenses, just a few
- common ones. I could use /usr/share/doc/common-licenses
- but I think this is too long, and, after all, the GPL
- does not "document" anything, it is merely a license.
- </p>
- </footnote>
+ files <tt>/usr/share/common-licenses/BSD</tt>,
+ <tt>/usr/share/common-licenses/Artistic</tt>,
+ <tt>/usr/share/common-licenses/GPL</tt>, and
+ <tt>/usr/share/common-licenses/LGPL</tt> respectively,
+ rather than quoting them in the copyright file.
</p>
<p>
should be installed in a directory
<tt>/usr/share/doc/<var>package</var>/examples</tt>. These
files should not be referenced by any program: they're there
- for the benefit of the system administrator and users, as
- documentation only. Architecture-specific example files
+ for the benefit of the system administrator and users as
+ documentation only. Architecture-specific example files
should be installed in a directory
- <tt>/usr/lib/<var>package</var>/examples</tt>, and files in
- <tt>/usr/share/doc/<var>package</var>/examples</tt> symlink
- to files in it. Or the latter directory may be a symlink to
- the former.</p>
+ <tt>/usr/lib/<var>package</var>/examples</tt> with symbolic
+ links to them from
+ <tt>/usr/share/doc/<var>package</var>/examples</tt>, or the
+ latter directory itself may be a symbolic link to the
+ former.
+ </p>
</sect>
<sect id="instchangelog">
<heading>Changelog files</heading>
<p>
- Packages that are not Debian-native must contain a copy of
- <tt>debian/changelog</tt> file from the Debian source tree
- in <tt>/usr/share/doc/<var>package</var></tt> as
- <tt>changelog.Debian.gz</tt>. If an upstream changelog is
+ Packages that are not Debian-native must contain a
+ compressed copy of the <tt>debian/changelog</tt> file from
+ the Debian source tree in
+ <tt>/usr/share/doc/<var>package</var></tt> with the name
+ <tt>changelog.Debian.gz</tt>. If an upstream changelog is
available, it should be accessible as
<tt>/usr/share/doc/<var>package</var>/changelog.gz</tt> in
- plain text. If the upstream changelog is distributed in
+ plain text. If the upstream changelog is distributed in
HTML, it should be made available in that form as
<tt>/usr/share/doc/<var>package</var>/changelog.html.gz</tt>
- and the <tt>changelog.gz</tt> should be generated using, eg,
- <tt>lynx -dump -nolist</tt>. If the upstream changelog files
- do not already conform to this naming convention, then this
- may be achieved either by renaming the files, or adding a
- symbolic link, at the maintainer's discretion.
- <footnote>
+ and a plain text <tt>changelog.gz</tt> should be generated
+ from it using, for example, <tt>lynx -dump -nolist</tt>. If
+ the upstream changelog files do not already conform to this
+ naming convention, then this may be achieved either by
+ renaming the files, or by adding a symbolic link, at the
+ maintainer's discretion.<footnote>
<p>
- Rationale: People should not have to look into two
- places for upstream changelogs merely because they are
- in HTML format.
+ Rationale: People should not have to look in places for
+ upstream changelogs merely because they are given
+ different names or are distributed in HTML format.
</p>
</footnote>
</p>
-
<p>
- All these files should be installed compressed using <tt>gzip -9</tt>,
- as they will become large with time even if they start out
- small.
+ All of these files should be installed compressed using
+ <tt>gzip -9</tt>, as they will become large with time even
+ if they start out small.
</p>
<p>
<tt>changelog.Debian.gz</tt>.</p>
</sect>
</chapt>
+
+ <appendix id="pkg-scope">
+ <heading>Introduction and scope of these appendices</heading>
+
+ <p>
+ These appendices are taken essentially verbatim from the
+ now-deprecated Packaging Manual, version 3.2.1.0. They are
+ the chapters which are likely to be of use to package
+ maintainers and which have not already been included in the
+ policy document itself. They have not yet been checked to
+ ensure that they are compatible with the contents of policy,
+ and if there are any contradictions, the version in the main
+ policy document takes precedence. The remaining chapters of
+ the old Packaging Manual have also not been read in detail to
+ ensure that there are not parts which have been left out.
+ Both of these will be done in due course.
+ </p>
+
+ <p>
+ <prgn>dpkg</prgn> is a suite of programs for creating binary
+ package files and installing and removing them on Unix
+ systems.<footnote>
+ <p>
+ <prgn>dpkg</prgn> is targetted primarily at Debian
+ GNU/Linux, but may work on or be ported to other
+ systems.
+ </p>
+ </footnote>
+ </p>
+
+ <p>
+ The binary packages are designed for the management of
+ installed executable programs (usually compiled binaries) and
+ their associated data, though source code examples and
+ documentation are provided as part of some packages.</p>
+
+ <p>
+ This manual describes the technical aspects of creating Debian
+ binary packages (<tt>.deb</tt> files). It documents the
+ behaviour of the package management programs
+ <prgn>dpkg</prgn>, <prgn>dselect</prgn> et al. and the way
+ they interact with packages.</p>
+
+ <p>
+ It also documents the interaction between
+ <prgn>dselect</prgn>'s core and the access method scripts it
+ uses to actually install the selected packages, and describes
+ how to create a new access method.</p>
+
+ <p>
+ This manual does not go into detail about the options and
+ usage of the package building and installation tools. It
+ should therefore be read in conjuction with those programs'
+ manpages.
+ </p>
+
+ <p>
+ The utility programs which are provided with <prgn>dpkg</prgn>
+ for managing various system configuration and similar issues,
+ such as <prgn>update-rc.d</prgn> and
+ <prgn>install-info</prgn>, are not described in detail here -
+ please see their manpages.
+ </p>
+
+ <p>
+ It does <em>not</em> describe the policy requirements imposed
+ on Debian packages, such as the permissions on files and
+ directories, documentation requirements, upload procedure, and
+ so on. You should see the Debian packaging policy manual for
+ these details. (Many of them will probably turn out to be
+ helpful even if you don't plan to upload your package and make
+ it available as part of the distribution.)
+ </p>
+
+ <p>
+ It is assumed that the reader is reasonably familiar with the
+ <prgn>dpkg</prgn> System Administrators' manual.
+ Unfortunately this manual does not yet exist.
+ </p>
+
+ <p>
+ The Debian version of the FSF's GNU hello program is provided
+ as an example for people wishing to create Debian
+ packages. The Debian <prgn>debmake</prgn> package is
+ recommended as a very helpful tool in creating and maintaining
+ Debian packages. However, while the tools and examples are
+ helpful, they do not replace the need to read and follow the
+ Policy and Programmer's Manual.</p>
+ </appendix>
+
+ <appendix id="pkg-binarypkg"><heading>Binary packages (from old
+ Packaging Manual)
+ </heading>
+
+ <p>
+ The binary package has two main sections. The first part
+ consists of various control information files and scripts used
+ by <prgn>dpkg</prgn> when installing and removing. See <ref
+ id="pkg-controlarea">.
+ </p>
+
+ <p>
+ The second part is an archive containing the files and
+ directories to be installed.
+ </p>
+
+ <p>
+ In the future binary packages may also contain other
+ components, such as checksums and digital signatures. The
+ format for the archive is described in full in the
+ <tt>deb(5)</tt> manpage.
+ </p>
+
+
+ <sect id="pkg-bincreating"><heading>Creating package files -
+ <prgn>dpkg-deb</prgn>
+ </heading>
+
+ <p>
+ All manipulation of binary package files is done by
+ <prgn>dpkg-deb</prgn>; it's the only program that has
+ knowledge of the format. (<prgn>dpkg-deb</prgn> may be
+ invoked by calling <prgn>dpkg</prgn>, as <prgn>dpkg</prgn>
+ will spot that the options requested are appropriate to
+ <prgn>dpkg-deb</prgn> and invoke that instead with the same
+ arguments.)
+ </p>
+
+ <p>
+ In order to create a binary package you must make a
+ directory tree which contains all the files and directories
+ you want to have in the filesystem data part of the package.
+ In Debian-format source packages this directory is usually
+ <tt>debian/tmp</tt>, relative to the top of the package's
+ source tree.
+ </p>
+
+ <p>
+ They should have the locations (relative to the root of the
+ directory tree you're constructing) ownerships and
+ permissions which you want them to have on the system when
+ they are installed.
+ </p>
+
+ <p>
+ With current versions of <prgn>dpkg</prgn> the uid/username
+ and gid/groupname mappings for the users and groups being
+ used should be the same on the system where the package is
+ built and the one where it is installed.
+ </p>
+
+ <p>
+ You need to add one special directory to the root of the
+ miniature filesystem tree you're creating:
+ <prgn>DEBIAN</prgn>. It should contain the control
+ information files, notably the binary package control file
+ (see <ref id="pkg-controlfile">).
+ </p>
+
+ <p>
+ The <prgn>DEBIAN</prgn> directory will not appear in the
+ filesystem archive of the package, and so won't be installed
+ by <prgn>dpkg</prgn> when the package is installed.
+ </p>
+
+ <p>
+ When you've prepared the package, you should invoke:
+ <example>
+ dpkg --build <var>directory</var>
+ </example>
+ </p>
+
+ <p>
+ This will build the package in
+ <tt><var>directory</var>.deb</tt>. (<prgn>dpkg</prgn> knows
+ that <tt>--build</tt> is a <prgn>dpkg-deb</prgn> option, so
+ it invokes <prgn>dpkg-deb</prgn> with the same arguments to
+ build the package.)
+ </p>
+
+ <p>
+ See the manpage <manref name="dpkg-deb" section="8"> for details of how
+ to examine the contents of this newly-created file. You may find the
+ output of following commands enlightening:
+ <example>
+ dpkg-deb --info <var>filename</var>.deb
+ dpkg-deb --contents <var>filename</var>.deb
+ dpkg --contents <var>filename</var>.deb
+ </example>
+ To view the copyright file for a package you could use this command:
+ <example>
+ dpkg --fsys-tarfile <var>filename</var>.deb | tar xof usr/doc/<var>\*</var>copyright | less
+ </example>
+ </p>
+ </sect>
+
+ <sect id="pkg-controlarea">
+ <heading>
+ Package control information files
+ </heading>
+
+ <p>
+ The control information portion of a binary package is a
+ collection of files with names known to <prgn>dpkg</prgn>.
+ It will treat the contents of these files specially - some
+ of them contain information used by <prgn>dpkg</prgn> when
+ installing or removing the package; others are scripts which
+ the package maintainer wants <prgn>dpkg</prgn> to run.
+ </p>
+
+ <p>
+ It is possible to put other files in the package control
+ area, but this is not generally a good idea (though they
+ will largely be ignored).
+ </p>
+
+ <p>
+ Here is a brief list of the control info files supported by
+ <prgn>dpkg</prgn> and a summary of what they're used for.
+ </p>
+
+ <p>
+ <taglist>
+ <tag><tt>control</tt>
+ <item>
+
+ <p>
+ This is the key description file used by
+ <prgn>dpkg</prgn>. It specifies the package's name
+ and version, gives its description for the user,
+ states its relationships with other packages, and so
+ forth. See <ref id="pkg-controlfile">.
+ </p>
+
+ <p>
+ It is usually generated automatically from information
+ in the source package by the
+ <prgn>dpkg-gencontrol</prgn> program, and with
+ assistance from <prgn>dpkg-shlibdeps</prgn>. See <ref
+ id="pkg-sourcetools">.</p>
+ </item>
+
+ <tag><tt>postinst</tt>, <tt>preinst</tt>, <tt>postrm</tt>,
+ <tt>prerm</tt>
+ </tag>
+ <item>
+
+ <p>
+ These are exectuable files (usually scripts) which
+ <prgn>dpkg</prgn> runs during installation, upgrade
+ and removal of packages. They allow the package to
+ deal with matters which are particular to that package
+ or require more complicated processing than that
+ provided by <prgn>dpkg</prgn>. Details of when and
+ how they are called are in <ref
+ id="maintainerscripts">.
+ </p>
+
+ <p>
+ It is very important to make these scripts
+ idempotent.
+ <footnote>
+ <p>
+ That means that if it runs successfully or fails
+ and then you call it again it doesn't bomb out,
+ but just ensures that everything is the way it
+ ought to be.
+ </p>
+ </footnote> This is so that if an error occurs, the
+ user interrupts <prgn>dpkg</prgn> or some other
+ unforeseen circumstance happens you don't leave the
+ user with a badly-broken package.
+ </p>
+
+ <p>
+ The maintainer scripts are guaranteed to run with a
+ controlling terminal and can interact with the user.
+ If they need to prompt for passwords, do full-screen
+ interaction or something similar you should do these
+ things to and from <tt>/dev/tty</tt>, since
+ <prgn>dpkg</prgn> will at some point redirect scripts'
+ standard input and output so that it can log the
+ installation process. Likewise, because these scripts
+ may be executed with standard output redirected into a
+ pipe for logging purposes, Perl scripts should set
+ unbuffered output by setting <tt>$|=1</tt> so that the
+ output is printed immediately rather than being
+ buffered.
+ </p>
+
+ <p>
+ Each script should return a zero exit status for
+ success, or a nonzero one for failure.</p>
+ </item>
+
+ <tag><tt>conffiles</tt>
+ </tag>
+ <item>
+
+ <p>
+ This file contains a list of configuration files which
+ are to be handled automatically by <prgn>dpkg</prgn>
+ (see <ref id="pkg-conffiles">). Note that not necessarily
+ every configuration file should be listed here.</p>
+ </item>
+
+ <tag><tt>shlibs</tt>
+ </tag>
+ <item>
+
+ <p>
+ This file contains a list of the shared libraries
+ supplied by the package, with dependency details for
+ each. This is used by <prgn>dpkg-shlibdeps</prgn>
+ when it determines what dependencies are required in a
+ package control file. The <tt>shlibs</tt> file format
+ is described on <ref id="shlibs">.
+ </p>
+ </item>
+ </taglist>
+ </p>
+
+ <sect id="pkg-controlfile">
+ <heading>
+ The main control information file: <tt>control</tt>
+ </heading>
+ <p>
+ The most important control information file used by
+ <prgn>dpkg</prgn> when it installs a package is
+ <tt>control</tt>. It contains all the package's `vital
+ statistics'.
+ </p>
+
+ <p>
+ The binary package control files of packages built from
+ Debian sources are made by a special tool,
+ <prgn>dpkg-gencontrol</prgn>, which reads
+ <tt>debian/control</tt> and <tt>debian/changelog</tt> to
+ find the information it needs. See <ref id="pkg-sourcepkg"> for
+ more details.
+ </p>
+
+ <p>
+ The fields in binary package control files are:
+ <list compact="compact">
+ <item>
+ <p><qref id="pkg-f-Package"><tt>Package</tt></qref> (mandatory)</p>
+ </item>
+ <item>
+ <p><qref id="versions"><tt>Version</tt></qref> (mandatory)</p>
+ </item>
+ <item><p><qref id="pkg-f-Architecture"><tt>Architecture</tt></qref>
+ (mandatory)
+ <footnote>
+ <p>
+ This field should appear in all packages, though
+ <prgn>dpkg</prgn> doesn't require it yet so that
+ old packages can still be installed.
+ </p>
+ </footnote>
+ </p>
+ </item>
+ <item>
+ <p><qref id="relationships"><tt>Depends</tt>,
+ <tt>Provides</tt> et al.</qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Essential"><tt>Essential</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Maintainer"><tt>Maintainer</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-classification"><tt>Section</tt>,
+ <tt>Priority</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Source"><tt>Source</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="descriptions"><tt>Description</tt></qref></p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Installed-Size"><tt>Installed-Size</tt></qref>
+ </p>
+ </item>
+ </list>
+
+ <p>
+ A description of the syntax of control files and the purpose
+ of these fields is available in <ref id="pkg-controlfields">.
+ </p>
+ </sect>
+
+ <sect>
+ <heading>Time Stamps</heading>
+ <p>
+ Maintainers are encouraged to preserve the modification
+ times of the upstream source files in a package, as far as
+ is reasonably possible.
+ <footnote>
+ <p>
+ The rationale is that there is some information conveyed
+ by knowing the age of the file, for example, you could
+ recognize that some documentation is very old by looking
+ at the modification time, so it would be nice if the
+ modification time of the upstream source would be
+ preserved.
+ </p>
+ </footnote>
+ </p>
+ </sect>
+ </appendix>
+
+ <appendix id="pkg-sourcepkg">
+ <heading>Source packages (from old Packaging Manual) </heading>
+
+ <p>
+ The Debian binary packages in the distribution are generated
+ from Debian sources, which are in a special format to assist
+ the easy and automatic building of binaries.
+ </p>
+
+ <p>
+ There was a previous version of the Debian source format,
+ which is now being phased out. Instructions for converting an
+ old-style package are given in the Debian policy manual.
+ </p>
+
+ <sect id="pkg-sourcetools">
+ <heading>Tools for processing source packages</heading>
+
+ <p>
+ Various tools are provided for manipulating source packages;
+ they pack and unpack sources and help build of binary
+ packages and help manage the distribution of new versions.
+ </p>
+
+ <p>
+ They are introduced and typical uses described here; see
+ <manref name="dpkg-source" section="1"> for full
+ documentation about their arguments and operation.
+ </p>
+
+ <p>
+ For examples of how to construct a Debian source package,
+ and how to use those utilities that are used by Debian
+ source packages, please see the <prgn>hello</prgn> example
+ package.
+ </p>
+
+ <sect1>
+ <heading>
+ <prgn>dpkg-source</prgn> - packs and unpacks Debian source
+ packages
+ </heading>
+
+ <p>
+ This program is frequently used by hand, and is also
+ called from package-independent automated building scripts
+ such as <prgn>dpkg-buildpackage</prgn>.
+ </p>
+
+ <p>
+ To unpack a package it is typically invoked with
+ <example>
+ dpkg-source -x <var>.../path/to/filename</var>.dsc
+ </example>
+ </p>
+
+ <p>
+ with the <tt><var>filename</var>.tar.gz</tt> and
+ <tt><var>filename</var>.diff.gz</tt> (if applicable) in
+ the same directory. It unpacks into
+ <tt><var>package</var>-<var>version</var></tt>, and if
+ applicable
+ <tt><var>package</var>-<var>version</var>.orig</tt>, in
+ the current directory.
+ </p>
+
+ <p>
+ To create a packed source archive it is typically invoked:
+ <example>
+ dpkg-source -b <var>package</var>-<var>version</var>
+ </example>
+ </p>
+
+ <p>
+ This will create the <tt>.dsc</tt>, <tt>.tar.gz</tt> and
+ <tt>.diff.gz</tt> (if appropriate) in the current
+ directory. <prgn>dpkg-source</prgn> does not clean the
+ source tree first - this must be done separately if it is
+ required.
+ </p>
+
+ <p>
+ See also <ref id="pkg-sourcearchives">.</p>
+ </sect1>
+
+
+ <sect1>
+ <heading>
+ <prgn>dpkg-buildpackage</prgn> - overall package-building
+ control script
+ </heading>
+
+ <p>
+ <prgn>dpkg-buildpackage</prgn> is a script which invokes
+ <prgn>dpkg-source</prgn>, the <tt>debian/rules</tt>
+ targets <prgn>clean</prgn>, <prgn>build</prgn> and
+ <prgn>binary</prgn>, <prgn>dpkg-genchanges</prgn> and
+ <prgn>pgp</prgn> to build a signed source and binary
+ package upload.
+ </p>
+
+ <p>
+ It is usually invoked by hand from the top level of the
+ built or unbuilt source directory. It may be invoked with
+ no arguments; useful arguments include:
+ <taglist compact="compact">
+ <tag><tt>-uc</tt>, <tt>-us</tt></tag>
+ <item>
+ <p>
+ Do not PGP-sign the <tt>.changes</tt> file or the
+ source package <tt>.dsc</tt> file, respectively.</p>
+ </item>
+ <tag><tt>-p<var>pgp-command</var></tt></tag>
+ <item>
+ <p>
+ Invoke <var>pgp-command</var> instead of finding
+ <tt>pgp</tt> on the <prgn>PATH</prgn>.
+ <var>pgp-command</var> must behave just like
+ <prgn>pgp</prgn>.</p>
+ </item>
+ <tag><tt>-r<var>root-command</var></tt></tag>
+ <item>
+ <p>
+ When root privilege is required, invoke the command
+ <var>root-command</var>. <var>root-command</var>
+ should invoke its first argument as a command, from
+ the <prgn>PATH</prgn> if necessary, and pass its
+ second and subsequent arguments to the command it
+ calls. If no <var>root-command</var> is supplied
+ then <var>dpkg-buildpackage</var> will take no
+ special action to gain root privilege, so that for
+ most packages it will have to be invoked as root to
+ start with.</p>
+ </item>
+ <tag><tt>-b</tt>, <tt>-B</tt></tag>
+ <item>
+ <p>
+ Two types of binary-only build and upload - see
+ <manref name="dpkg-source" section="1">.
+ </p>
+ </item>
+ </taglist>
+ </p>
+ </sect1>
+
+ <sect1>
+ <heading>
+ <prgn>dpkg-gencontrol</prgn> - generates binary package
+ control files
+ </heading>
+
+ <p>
+ This program is usually called from <tt>debian/rules</tt>
+ (see <ref id="pkg-sourcetree">) in the top level of the source
+ tree.
+ </p>
+
+ <p>
+ This is usually done just before the files and directories in the
+ temporary directory tree where the package is being built have their
+ permissions and ownerships set and the package is constructed using
+ <prgn>dpkg-deb/</prgn>
+ <footnote>
+ <p>
+ This is so that the control file which is produced has
+ the right permissions
+ </p>
+ </footnote>.
+ </p>
+
+ <p>
+ <prgn>dpkg-gencontrol</prgn> must be called after all the
+ files which are to go into the package have been placed in
+ the temporary build directory, so that its calculation of
+ the installed size of a package is correct.
+ </p>
+
+ <p>
+ It is also necessary for <prgn>dpkg-gencontrol</prgn> to
+ be run after <prgn>dpkg-shlibdeps</prgn> so that the
+ variable substitutions created by
+ <prgn>dpkg-shlibdeps</prgn> in <tt>debian/substvars</tt>
+ are available.
+ </p>
+
+ <p>
+ For a package which generates only one binary package, and
+ which builds it in <tt>debian/tmp</tt> relative to the top
+ of the source package, it is usually sufficient to call
+ <prgn>dpkg-gencontrol</prgn>.
+ </p>
+
+ <p>
+ Sources which build several binaries will typically need
+ something like:
+ <example>
+ dpkg-gencontrol -Pdebian/tmp-<var>pkg</var> -p<var>package</var>
+ </example> The <tt>-P</tt> tells
+ <prgn>dpkg-gencontrol</prgn> that the package is being
+ built in a non-default directory, and the <tt>-p</tt>
+ tells it which package's control file should be generated.
+ </p>
+
+ <p>
+ <prgn>dpkg-gencontrol</prgn> also adds information to the
+ list of files in <tt>debian/files</tt>, for the benefit of
+ (for example) a future invocation of
+ <prgn>dpkg-genchanges</prgn>.</p>
+ </sect1>
+
+ <sect1>
+ <heading>
+ <prgn>dpkg-shlibdeps</prgn> - calculates shared library
+ dependencies
+ </heading>
+
+ <p>
+ This program is usually called from <tt>debian/rules</tt>
+ just before <prgn>dpkg-gencontrol</prgn> (see <ref
+ id="pkg-sourcetree">), in the top level of the source tree.
+ </p>
+
+ <p>
+ Its arguments are executables.
+ <footnote>
+ <p>
+ In a forthcoming dpkg version,
+ <prgn>dpkg-shlibdeps</prgn> would be required to be
+ called on shared libraries as well.
+ </p>
+ <p>
+ They may be specified either in the locations in the
+ source tree where they are created or in the locations
+ in the temporary build tree where they are installed
+ prior to binary package creation.
+ </p>
+ </footnote> for which shared library dependencies should
+ be included in the binary package's control file.
+ </p>
+
+ <p>
+ If some of the found shared libraries should only
+ warrant a <tt>Recommends</tt> or <tt>Suggests</tt>, or if
+ some warrant a <tt>Pre-Depends</tt>, this can be achieved
+ by using the <tt>-d<var>dependency-field</var></tt> option
+ before those executable(s). (Each <tt>-d</tt> option
+ takes effect until the next <tt>-d</tt>.)
+ </p>
+
+ <p>
+ <prgn>dpkg-shlibdeps</prgn> does not directly cause the
+ output control file to be modified. Instead by default it
+ adds to the <tt>debian/substvars</tt> file variable
+ settings like <tt>shlibs:Depends</tt>. These variable
+ settings must be referenced in dependency fields in the
+ appropriate per-binary-package sections of the source
+ control file.
+ </p>
+
+ <p>
+ For example, the <prgn>procps</prgn> package generates two
+ kinds of binaries, simple C binaries like <prgn>ps</prgn>
+ which require a predependency and full-screen ncurses
+ binaries like <prgn>top</prgn> which require only a
+ recommendation. It can say in its <tt>debian/rules</tt>:
+ <example>
+ dpkg-shlibdeps -dPre-Depends ps -dRecommends top
+ </example>
+ and then in its main control file <tt>debian/control</tt>:
+ <example>
+ <var>...</var>
+ Package: procps
+ Pre-Depends: ${shlibs:Pre-Depends}
+ Recommends: ${shlibs:Recommends}
+ <var>...</var>
+ </example>
+ </p>
+
+ <p>
+ Sources which produce several binary packages with
+ different shared library dependency requirements can use
+ the <tt>-p<var>varnameprefix</var></tt> option to override
+ the default <tt>shlib:</tt> prefix (one invocation of
+ <prgn>dpkg-shlibdeps</prgn> per setting of this option).
+ They can thus produce several sets of dependency
+ variables, each of the form
+ <tt><var>varnameprefix</var>:<var>dependencyfield</var></tt>,
+ which can be referred to in the appropriate parts of the
+ binary package control files.
+ </p>
+ </sect1>
+
+
+ <sect1>
+ <heading>
+ <prgn>dpkg-distaddfile</prgn> - adds a file to
+ <tt>debian/files</tt>
+ </heading>
+
+ <p>
+ Some packages' uploads need to include files other than
+ the source and binary package files.
+ </p>
+
+ <p>
+ <prgn>dpkg-distaddfile</prgn> adds a file to the
+ <tt>debian/files</tt> file so that it will be included in
+ the <tt>.changes</tt> file when
+ <prgn>dpkg-genchanges</prgn> is run.
+ </p>
+
+ <p>
+ It is usually invoked from the <prgn>binary</prgn> target of
+ <tt>debian/rules</tt>:
+ <example>
+ dpkg-distaddfile <var>filename</var> <var>section</var> <var>priority</var>
+ </example>
+ The <var>filename</var> is relative to the directory where
+ <prgn>dpkg-genchanges</prgn> will expect to find it - this
+ is usually the directory above the top level of the source
+ tree. The <tt>debian/rules</tt> target should put the
+ file there just before or just after calling
+ <prgn>dpkg-distaddfile</prgn>.
+ </p>
+
+ <p>
+ The <var>section</var> and <var>priority</var> are passed
+ unchanged into the resulting <tt>.changes</tt> file. See
+ <ref id="pkg-f-classification">.
+ </p>
+ </sect1>
+
+
+ <sect1><heading><prgn>dpkg-genchanges</prgn> - generates a <tt>.changes</tt> upload
+ control file
+ </heading>
+
+ <p>
+ This program is usually called by package-independent
+ automatic building scripts such as
+ <prgn>dpkg-buildpackage</prgn>, but it may also be called
+ by hand.
+ </p>
+
+ <p>
+ It is usually called in the top level of a built source
+ tree, and when invoked with no arguments will print out a
+ straightforward <tt>.changes</tt> file based on the
+ information in the source package's changelog and control
+ file and the binary and source packages which should have
+ been built.
+ </p>
+ </sect1>
+
+
+ <sect1><heading><prgn>dpkg-parsechangelog</prgn> - produces parsed representation of
+ a changelog
+ </heading>
+
+ <p>
+ This program is used internally by
+ <prgn>dpkg-source</prgn> et al. It may also occasionally
+ be useful in <tt>debian/rules</tt> and elsewhere. It
+ parses a changelog, <tt>debian/changelog</tt> by default,
+ and prints a control-file format representation of the
+ information in it to standard output.
+ </p>
+ </sect1>
+
+ <sect1 id="pkg-dpkgarch"><heading><prgn>dpkg-architecture</prgn> -
+ information about the build and host system
+ </heading>
+
+ <p>
+ This program can be used manually, but is also invoked by
+ <tt>dpkg-buildpackage</tt> or <tt>debian/rules</tt> to set
+ to set environment or make variables which specify the build and
+ host architecture for the package building process.
+ </p>
+ </sect1>
+ </sect>
+
+ <sect id="pkg-sourcetree"><heading>The Debianised source tree
+ </heading>
+
+ <p>
+ The source archive scheme described later is intended to
+ allow a Debianised source tree with some associated control
+ information to be reproduced and transported easily. The
+ Debianised source tree is a version of the original program
+ with certain files added for the benefit of the
+ Debianisation process, and with any other changes required
+ made to the rest of the source code and installation
+ scripts.
+ </p>
+
+ <p>
+ The extra files created for Debian are in the subdirectory
+ <tt>debian</tt> of the top level of the Debianised source
+ tree. They are described below.
+ </p>
+
+ <sect1 id="pkg-debianrules"><heading><tt>debian/rules</tt> - the main building
+ script
+ </heading>
+
+ <p>
+ This file is an executable makefile, and contains the
+ package-specific recipies for compiling the package and
+ building binary package(s) out of the source.
+ </p>
+
+ <p>
+ It must start with the line <tt>#!/usr/bin/make -f</tt>,
+ so that it can be invoked by saying its name rather than
+ invoking <prgn>make</prgn> explicitly.
+ </p>
+
+ <p>
+ Since an interactive <tt>debian/rules</tt> script makes it
+ impossible to autocompile that package and also makes it
+ hard for other people to reproduce the same binary
+ package, all <strong>required targets</strong> have to be
+ non-interactive. At a minimul, required targets are the
+ ones called by <prgn>dpkg-buildpackage</prgn>, namely,
+ <em>clean</em>, <em>binary</em>, <em>binary-arch</em>, and
+ <em>build</em>. It also follows that any target that these
+ targets depend on must also be non-interactive.
+ </p>
+
+ <p>
+ The targets which are required to be present are:
+ <taglist>
+ <tag><tt>build</tt></tag>
+ <item>
+ <p>
+ This should perform all non-interactive
+ configuration and compilation of the package. If a
+ package has an interactive pre-build configuration
+ routine, the Debianised source package should be
+ built after this has taken place, so that it can be
+ built without rerunning the configuration.
+ </p>
+
+ <p>
+ For some packages, notably ones where the same
+ source tree is compiled in different ways to produce
+ two binary packages, the <prgn>build</prgn> target
+ does not make much sense. For these packages it is
+ good enough to provide two (or more) targets
+ (<tt>build-a</tt> and <tt>build-b</tt> or whatever)
+ for each of the ways of building the package, and a
+ <prgn>build</prgn> target that does nothing. The
+ <prgn>binary</prgn> target will have to build the
+ package in each of the possible ways and make the
+ binary package out of each.
+ </p>
+
+ <p>
+ The <prgn>build</prgn> target must not do anything
+ that might require root privilege.
+ </p>
+
+ <p>
+ The <prgn>build</prgn> target may need to run
+ <prgn>clean</prgn> first - see below.
+ </p>
+
+ <p>
+ When a package has a configuration routine that
+ takes a long time, or when the makefiles are poorly
+ designed, or when <prgn>build</prgn> needs to run
+ <prgn>clean</prgn> first, it is a good idea to
+ <tt>touch build</tt> when the build process is
+ complete. This will ensure that if <tt>debian/rules
+ build</tt> is run again it will not rebuild the
+ whole program.
+ </p>
+ </item>
+
+ <tag><tt>binary</tt>, <tt>binary-arch</tt>,
+ <tt>binary-indep</tt>
+ </tag>
+ <item>
+ <p>
+ The <prgn>binary</prgn> target should be all that is
+ necessary for the user to build the binary
+ package. All these targets are required to be
+ non-interactive. It is split into two parts:
+ <prgn>binary-arch</prgn> builds the packages' output
+ files which are specific to a particular
+ architecture, and <prgn>binary-indep</prgn> builds
+ those which are not.
+ </p>
+
+ <p>
+ <prgn>binary</prgn> should usually be a target with
+ no commands which simply depends on
+ <prgn>binary-arch</prgn> and
+ <prgn>binary-indep</prgn>.
+ </p>
+
+ <p>
+ Both <prgn>binary-*</prgn> targets should depend on
+ the <prgn>build</prgn> target, above, so that the
+ package is built if it has not been already. It
+ should then create the relevant binary package(s),
+ using <prgn>dpkg-gencontrol</prgn> to make their
+ control files and <prgn>dpkg-deb</prgn> to build
+ them and place them in the parent of the top level
+ directory.
+ </p>
+
+ <p>
+ If one of the <prgn>binary-*</prgn> targets has
+ nothing to do (this will be always be the case if
+ the source generates only a single binary package,
+ whether architecture-dependent or not) it
+ <em>must</em> still exist, but should always
+ succeed.
+ </p>
+
+ <p>
+ <ref id="pkg-binarypkg"> describes how to construct
+ binary packages.
+ </p>
+
+ <p>
+ The <prgn>binary</prgn> targets must be invoked as
+ root.
+ </p>
+ </item>
+
+ <tag><tt>clean</tt></tag>
+ <item>
+
+ <p>
+ This should undo any effects that the
+ <prgn>build</prgn> and <prgn>binary</prgn> targets
+ may have had, except that it should leave alone any
+ output files created in the parent directory by a
+ run of <prgn>binary</prgn>. This target is required
+ to be non-interactive.
+ </p>
+
+ <p>
+ If a <prgn>build</prgn> file is touched at the end
+ of the <prgn>build</prgn> target, as suggested
+ above, it must be removed as the first thing that
+ <prgn>clean</prgn> does, so that running
+ <prgn>build</prgn> again after an interrupted
+ <prgn>clean</prgn> doesn't think that everything is
+ already done.
+ </p>
+
+ <p>
+ The <prgn>clean</prgn> target must be invoked as
+ root if <prgn>binary</prgn> has been invoked since
+ the last <prgn>clean</prgn>, or if
+ <prgn>build</prgn> has been invoked as root (since
+ <prgn>build</prgn> may create directories, for
+ example).
+ </p>
+ </item>
+
+ <tag><tt>get-orig-source</tt> (optional)</tag>
+ <item>
+
+ <p>
+ This target fetches the most recent version of the
+ original source package from a canonical archive
+ site (via FTP or WWW, for example), does any
+ necessary rearrangement to turn it into the original
+ source tarfile format described below, and leaves it
+ in the current directory.
+ </p>
+
+ <p>
+ This target may be invoked in any directory, and
+ should take care to clean up any temporary files it
+ may have left.
+ </p>
+
+ <p>
+ This target is optional, but providing it if
+ possible is a good idea.
+ </p>
+ </item>
+ </taglist>
+
+ <p>
+ The <prgn>build</prgn>, <prgn>binary</prgn> and
+ <prgn>clean</prgn> targets must be invoked with a current
+ directory of the package's top-level directory.
+ </p>
+
+
+ <p>
+ Additional targets may exist in <tt>debian/rules</tt>,
+ either as published or undocumented interfaces or for the
+ package's internal use.
+ </p>
+
+ <p>
+ The architecture we build on and build for is determined by make
+ variables via dpkg-architecture (see <ref id="pkg-dpkgarch">). You can
+ get the Debian architecture and the GNU style architecture
+ specification string for the build machine as well as the host
+ machine. Here is a list of supported make variables:
+ <list compact="compact">
+ <item>
+ <p><tt>DEB_*_ARCH</tt> (the Debian architecture)</p>
+ </item>
+ <item>
+ <p><tt>DEB_*_GNU_TYPE</tt> (the GNU style architecture
+ specification string)</p>
+ </item>
+ <item>
+ <p><tt>DEB_*_GNU_CPU</tt> (the CPU part of DEB_*_GNU_TYPE)</p>
+ </item>
+ <item>
+ <p><tt>DEB_*_GNU_SYSTEM</tt> (the System part of
+ DEB_*_GNU_TYPE)</p>
+ </list>
+ </p>
+
+ <p>
+ where <tt>*</tt> is either <tt>BUILD</tt> for specification of
+ the build machine or <tt>HOST</tt> for specification of the machine
+ we build for.
+ </p>
+
+ <p>
+ Backward compatibility can be provided in the rules file
+ by setting the needed variables to suitable default
+ values, please refer to the documentation of
+ dpkg-architecture for details.
+ </p>
+
+ <p>
+ It is important to understand that the <tt>DEB_*_ARCH</tt>
+ string does only determine which Debian architecture we
+ build on resp. for. It should not be used to get the CPU
+ or System information, the GNU style variables should be
+ used for that.
+ </p>
+ </sect1>
+
+
+ <sect1><heading><tt>debian/control</tt>
+ </heading>
+
+ <p>
+ This file contains version-independent details about the
+ source package and about the binary packages it creates.
+ </p>
+
+ <p>
+ It is a series of sets of control fields, each
+ syntactically similar to a binary package control file.
+ The sets are separated by one or more blank lines. The
+ first set is information about the source package in
+ general; each subsequent set describes one binary package
+ that the source tree builds.
+ </p>
+
+ <p>
+ The syntax and semantics of the fields are described below
+ in <ref id="pkg-controlfields">.
+ </p>
+
+ <p>
+ The general (binary-package-independent) fields are:
+ <list compact="compact">
+ <item>
+ <p><qref id="pkg-f-Source"><tt>Source</tt></qref> (mandatory)</p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Maintainer"><tt>Maintainer</tt></qref></p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-classification"><tt>Section</tt> and
+ <tt>Priority</tt></qref>
+ (classification, mandatory)
+ </p>
+ </item>
+ <item>
+ <p>
+ <qref id="relationships"><tt>Build-Depends</tt> et
+ al.</qref> (source package interrelationships)
+ </p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Standards-Version"><tt>Standards-Version</tt></qref>
+ </p>
+ </item>
+ </list>
+
+ <p>
+ The per-binary-package fields are:
+ <list compact="compact">
+ <item>
+ <p><qref id="pkg-f-Package"><tt>Package</tt></qref> (mandatory)</p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Architecture"><tt>Architecture</tt></qref>
+ (mandatory)</p>
+ </item>
+ <item>
+ <p><qref id="descriptions"><tt>Description</tt></qref></p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-classification"><tt>Section</tt> and
+ <tt>Priority</tt></qref> (classification)</p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Essential"><tt>Essential</tt></qref></p>
+ </item>
+ <item>
+ <p>
+ <qref id="relationships"><tt>Depends</tt> et
+ al.</qref> (binary package interrelationships)
+ </p>
+ </item>
+ </list>
+
+ <p>
+ These fields are used by <prgn>dpkg-gencontrol</prgn> to
+ generate control files for binary packages (see below), by
+ <prgn>dpkg-genchanges</prgn> to generate the
+ <tt>.changes</tt> file to accompany the upload, and by
+ <prgn>dpkg-source</prgn> when it creates the <tt>.dsc</tt>
+ source control file as part of a source archive.
+ </p>
+
+ <p>
+ The fields here may contain variable references - their
+ values will be substituted by
+ <prgn>dpkg-gencontrol</prgn>, <prgn>dpkg-genchanges</prgn>
+ or <prgn>dpkg-source</prgn> when they generate output
+ control files. See <ref id="pkg-srcsubstvars"> for details.
+ </p>
+
+ <p> <sect2><heading>User-defined fields
+ </heading>
+
+ <p>
+ Additional user-defined fields may be added to the
+ source package control file. Such fields will be
+ ignored, and not copied to (for example) binary or
+ source package control files or upload control files.
+ </p>
+
+ <p>
+ If you wish to add additional unsupported fields to
+ these output files you should use the mechanism
+ described here.
+ </p>
+
+ <p>
+ Fields in the main source control information file with
+ names starting <tt>X</tt>, followed by one or more of
+ the letters <tt>BCS</tt> and a hyphen <tt>-</tt>, will
+ be copied to the output files. Only the part of the
+ field name after the hyphen will be used in the output
+ file. Where the letter <tt>B</tt> is used the field
+ will appear in binary package control files, where the
+ letter <tt>S</tt> is used in source package control
+ files and where <tt>C</tt> is used in upload control
+ (<tt>.changes</tt>) files.
+ </p>
+
+ <p>
+ For example, if the main source information control file
+ contains the field
+ <example>
+ XBS-Comment: I stand between the candle and the star.
+ </example>
+ then the binary and source package control files will contain the
+ field
+ <example>
+ Comment: I stand between the candle and the star.
+ </example>
+ </p>
+ </sect2>
+
+ </sect1>
+
+ <sect1 id="pkg-dpkgchangelog"><heading><tt>debian/changelog</tt>
+ </heading>
+
+ <p>
+ This file records the changes to the Debian-specific parts of the
+ package
+ <footnote>
+ <p>
+ Though there is nothing stopping an author who is also
+ the Debian maintainer from using it for all their
+ changes, it will have to be renamed if the Debian and
+ upstream maintainers become different
+ people.
+ </p>
+ </footnote>.
+ </p>
+
+ <p>
+ It has a special format which allows the package building
+ tools to discover which version of the package is being
+ built and find out other release-specific information.
+ </p>
+
+ <p>
+ That format is a series of entries like this:
+ <example>
+ <var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
+
+ * <var>change details</var>
+ <var>more change details</var>
+ * <var>even more change details</var>
+
+ -- <var>maintainer name and email address</var> <var>date</var>
+ </example>
+ </p>
+
+ <p>
+ <var>package</var> and <var>version</var> are the source
+ package name and version number.
+ </p>
+
+ <p>
+ <var>distribution(s)</var> lists the distributions where
+ this version should be installed when it is uploaded - it
+ is copied to the <tt>Distribution</tt> field in the
+ <tt>.changes</tt> file. See <ref id="pkg-f-Distribution">.
+ </p>
+
+ <p>
+ <var>urgency</var> is the value for the <tt>Urgency</tt>
+ field in the <tt>.changes</tt> file for the upload. See
+ <ref id="pkg-f-Urgency">. It is not possible to specify an
+ urgency containing commas; commas are used to separate
+ <tt><var>keyword</var>=<var>value</var></tt> settings in
+ the <prgn>dpkg</prgn> changelog format (though there is
+ currently only one useful <var>keyword</var>,
+ <tt>urgency</tt>).
+ </p>
+
+ <p>
+ The change details may in fact be any series of lines
+ starting with at least two spaces, but conventionally each
+ change starts with an asterisk and a separating space and
+ continuation lines are indented so as to bring them in
+ line with the start of the text above. Blank lines may be
+ used here to separate groups of changes, if desired.
+ </p>
+
+ <p>
+ The maintainer name and email address should <em>not</em>
+ necessarily be those of the usual package maintainer.
+ They should be the details of the person doing
+ <em>this</em> version. The information here will be
+ copied to the <tt>.changes</tt> file, and then later used
+ to send an acknowledgement when the upload has been
+ installed.
+ </p>
+
+ <p>
+ The <var>date</var> should be in RFC822 format
+ <footnote>
+ <p>
+ This is generated by the <prgn>822-date</prgn>
+ program.
+ </p>
+ </footnote>; it should include the timezone specified
+ numerically, with the timezone name or abbreviation
+ optionally present as a comment.
+ </p>
+
+ <p>
+ The first `title' line with the package name should start
+ at the left hand margin; the `trailer' line with the
+ maintainer and date details should be preceded by exactly
+ one space. The maintainer details and the date must be
+ separated by exactly two spaces.
+ </p>
+
+ <p>
+ An Emacs mode for editing this format is available: it is
+ called <tt>debian-changelog-mode</tt>. You can have this
+ mode selected automatically when you edit a Debian
+ changelog by adding a local variables clause to the end of
+ the changelog.
+ </p>
+
+ <sect2><heading>Defining alternative changelog formats
+ </heading>
+
+ <p>
+ It is possible to use a different format to the standard
+ one, by providing a parser for the format you wish to
+ use.
+ </p>
+
+ <p>
+ In order to have <tt>dpkg-parsechangelog</tt> run your
+ parser, you must include a line within the last 40 lines
+ of your file matching the Perl regular expression:
+ <tt>\schangelog-format:\s+([0-9a-z]+)\W</tt> The part in
+ parentheses should be the name of the format. For
+ example, you might say:
+ <example>
+ @@@ changelog-format: joebloggs @@@
+ </example>
+ Changelog format names are non-empty strings of alphanumerics.
+ </p>
+
+ <p>
+ If such a line exists then <tt>dpkg-parsechangelog</tt>
+ will look for the parser as
+ <tt>/usr/lib/dpkg/parsechangelog/<var>format-name</var></tt>
+ or
+ <tt>/usr/local/lib/dpkg/parsechangelog/<var>format-name</var></tt>;
+ it is an error for it not to find it, or for it not to
+ be an executable program. The default changelog format
+ is <tt>dpkg</tt>, and a parser for it is provided with
+ the <tt>dpkg</tt> package.
+ </p>
+
+ <p>
+ The parser will be invoked with the changelog open on
+ standard input at the start of the file. It should read
+ the file (it may seek if it wishes) to determine the
+ information required and return the parsed information
+ to standard output in the form of a series of control
+ fields in the standard format. By default it should
+ return information about only the most recent version in
+ the changelog; it should accept a
+ <tt>-v<var>version</var></tt> option to return changes
+ information from all versions present <em>strictly
+ after</em> <var>version</var>, and it should then be an
+ error for <var>version</var> not to be present in the
+ changelog.
+ </p>
+
+ <p>
+ The fields are:
+ <list compact="compact">
+ <item>
+ <p><qref id="pkg-f-Source"><tt>Source</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="versions"><tt>Version</tt></qref> (mandatory)</p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Distribution"><tt>Distribution</tt></qref>
+ (mandatory)
+ </p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Urgency"><tt>Urgency</tt></qref> (mandatory)</p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Maintainer"><tt>Maintainer</tt></qref>
+ (mandatory)
+ </p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Date"><tt>Date</tt></qref></p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Changes"><tt>Changes</tt></qref>
+ (mandatory)
+ </p>
+ </item>
+ </list>
+
+ <p>
+ If several versions are being returned (due to the use
+ of <tt>-v</tt>), the urgency value should be of the
+ highest urgency code listed at the start of any of the
+ versions requested followed by the concatenated
+ (space-separated) comments from all the versions
+ requested; the maintainer, version, distribution and
+ date should always be from the most recent version.
+ </p>
+
+ <p>
+ For the format of the <tt>Changes</tt> field see <ref
+ id="pkg-f-Changes">.
+ </p>
+
+ <p>
+ If the changelog format which is being parsed always or
+ almost always leaves a blank line between individual
+ change notes these blank lines should be stripped out,
+ so as to make the resulting output compact.
+ </p>
+
+ <p>
+ If the changelog format does not contain date or package
+ name information this information should be omitted from
+ the output. The parser should not attempt to synthesise
+ it or find it from other sources.
+ </p>
+
+ <p>
+ If the changelog does not have the expected format the
+ parser should exit with a nonzero exit status, rather
+ than trying to muddle through and possibly generating
+ incorrect output.
+ </p>
+
+ <p>
+ A changelog parser may not interact with the user at
+ all.</p></sect2>
+ </sect1>
+
+ <sect1 id="pkg-srcsubstvars"><heading><tt>debian/substvars</tt>
+ and variable substitutions
+ </heading>
+
+ <p>
+ When <prgn>dpkg-gencontrol</prgn>,
+ <prgn>dpkg-genchanges</prgn> and <prgn>dpkg-source</prgn>
+ generate control files they do variable substitutions on
+ their output just before writing it. Variable
+ substitutions have the form
+ <tt>${<var>variable-name</var>}</tt>. The optional file
+ <tt>debian/substvars</tt> contains variable substitutions
+ to be used; variables can also be set directly from
+ <tt>debian/rules</tt> using the <tt>-V</tt> option to the
+ source packaging commands, and certain predefined
+ variables are available.
+ </p>
+
+ <p>
+ The is usually generated and modified dynamically by
+ <tt>debian/rules</tt> targets; in this case it must be
+ removed by the <prgn>clean</prgn> target.
+ </p>
+
+ <p>
+ See <manref name="dpkg-source" section="1"> for full
+ details about source variable substitutions, including the
+ format of <tt>debian/substvars</tt>.</p>
+ </sect1>
+
+ <sect1><heading><tt>debian/files</tt>
+ </heading>
+
+ <p>
+ This file is not a permanent part of the source tree; it
+ is used while building packages to record which files are
+ being generated. <prgn>dpkg-genchanges</prgn> uses it
+ when it generates a <tt>.changes</tt> file.
+ </p>
+
+ <p>
+ It should not exist in a shipped source package, and so it
+ (and any backup files or temporary files such as
+ <tt>files.new</tt>
+ <footnote>
+ <p>
+ <tt>files.new</tt> is used as a temporary file by
+ <prgn>dpkg-gencontrol</prgn> and
+ <prgn>dpkg-distaddfile</prgn> - they write a new
+ version of <tt>files</tt> here before renaming it,
+ to avoid leaving a corrupted copy if an error
+ occurs
+ </p>
+ </footnote>) should be removed by the
+ <prgn>clean</prgn> target. It may also be wise to
+ ensure a fresh start by emptying or removing it at the
+ start of the <prgn>binary</prgn> target.
+ </p>
+
+ <p>
+ <prgn>dpkg-gencontrol</prgn> adds an entry to this file
+ for the <tt>.deb</tt> file that will be created by
+ <prgn>dpkg-deb</prgn> from the control file that it
+ generates, so for most packages all that needs to be done
+ with this file is to delete it in <prgn>clean</prgn>.
+ </p>
+
+ <p>
+ If a package upload includes files besides the source
+ package and any binary packages whose control files were
+ made with <prgn>dpkg-gencontrol</prgn> then they should be
+ placed in the parent of the package's top-level directory
+ and <prgn>dpkg-distaddfile</prgn> should be called to add
+ the file to the list in <tt>debian/files</tt>.</p>
+ </sect1>
+
+ <sect1><heading><tt>debian/tmp</tt>
+ </heading>
+
+ <p>
+ This is the canonical temporary location for the
+ construction of binary packages by the <prgn>binary</prgn>
+ target. The directory <tt>tmp</tt> serves as the root of
+ the filesystem tree as it is being constructed (for
+ example, by using the package's upstream makefiles install
+ targets and redirecting the output there), and it also
+ contains the <tt>DEBIAN</tt> subdirectory. See <ref
+ id="pkg-bincreating">.
+ </p>
+
+ <p>
+ If several binary packages are generated from the same
+ source tree it is usual to use several
+ <tt>debian/tmp<var>something</var></tt> directories, for
+ example <tt>tmp-a</tt> or <tt>tmp-doc</tt>.
+ </p>
+
+ <p>
+ Whatever <tt>tmp</tt> directories are created and used by
+ <prgn>binary</prgn> must of course be removed by the
+ <prgn>clean</prgn> target.</p></sect1>
+ </sect>
+
+
+ <sect id="pkg-sourcearchives"><heading>Source packages as archives
+ </heading>
+
+ <p>
+ As it exists on the FTP site, a Debian source package
+ consists of three related files. You must have the right
+ versions of all three to be able to use them.
+ </p>
+
+ <p>
+ <taglist>
+ <tag>Debian source control file - <tt>.dsc</tt></tag>
+ <item>
+
+ <p>
+ This file contains a series of fields, identified and
+ separated just like the fields in the control file of
+ a binary package. The fields are listed below; their
+ syntax is described above, in <ref id="pkg-controlfields">.
+ <list compact="compact">
+ <item>
+ <p><qref id="pkg-f-Source"><tt>Source</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="versions"><tt>Version</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Maintainer"><tt>Maintainer</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Binary"><tt>Binary</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Architecture"><tt>Architecture</tt></qref></p>
+ </item>
+ <item>
+ <p>
+ <qref id="relationships"><tt>Build-Depends</tt> et
+ al.</qref> (source package interrelationships)
+ </p>
+ </item>
+ <item>
+ <p>
+ <qref id="pkg-f-Standards-Version"><tt>Standards-Version</tt></qref></p>
+ </item>
+ <item>
+ <p><qref id="pkg-f-Files"><tt>Files</tt></qref></p>
+ </item>
+ </list>
+
+ <p>
+ The source package control file is generated by
+ <prgn>dpkg-source</prgn> when it builds the source
+ archive, from other files in the source package,
+ described above. When unpacking it is checked against
+ the files and directories in the other parts of the
+ source package, as described below.</p>
+ </item>
+
+ <tag>
+ Original source archive -
+ <tt>
+ <var>package</var>_<var>upstream-version</var>.orig.tar.gz
+ </tt>
+ </tag>
+
+ <item>
+
+ <p>
+ This is a compressed (with <tt>gzip -9</tt>)
+ <prgn>tar</prgn> file containing the source code from
+ the upstream authors of the program. The tarfile
+ unpacks into a directory
+ <tt><var>package</var>-<var>upstream-version</var>.orig</tt>,
+ and does not contain files anywhere other than in
+ there or in its subdirectories.</p>
+ </item>
+
+ <tag>
+ Debianisation diff -
+ <tt>
+ <var>package</var>_<var>upstream_version-revision</var>.diff.gz
+ </tt>
+ </tag>
+ <item>
+
+ <p>
+ This is a unified context diff (<tt>diff -u</tt>)
+ giving the changes which are required to turn the
+ original source into the Debian source. These changes
+ may only include editing and creating plain files.
+ The permissions of files, the targets of symbolic
+ links and the characteristics of special files or
+ pipes may not be changed and no files may be removed
+ or renamed.
+ </p>
+
+ <p>
+ All the directories in the diff must exist, except the
+ <tt>debian</tt> subdirectory of the top of the source
+ tree, which will be created by
+ <prgn>dpkg-source</prgn> if necessary when unpacking.
+ </p>
+
+ <p>
+ The <prgn>dpkg-source</prgn> program will
+ automatically make the <tt>debian/rules</tt> file
+ executable (see below).</p></item>
+ </taglist>
+
+
+ <p>
+ If there is no original source code - for example, if the
+ package is specially prepared for Debian or the Debian
+ maintainer is the same as the upstream maintainer - the
+ format is slightly different: then there is no diff, and the
+ tarfile is named
+ <tt><var>package</var>_<var>version</var>.tar.gz</tt> and
+ contains a directory
+ <tt><var>package</var>-<var>version</var></tt>.
+ </p>
+ </sect>
+
+ <sect><heading>Unpacking a Debian source package without
+ <prgn>dpkg-source</prgn>
+ </heading>
+
+ <p>
+ <tt>dpkg-source -x</tt> is the recommended way to unpack a
+ Debian source package. However, if it is not available it
+ is possible to unpack a Debian source archive as follows:
+ <enumlist compact="compact">
+ <item>
+ <p>
+ Untar the tarfile, which will create a <tt>.orig</tt>
+ directory.</p>
+ </item>
+ <item>
+ <p>Rename the <tt>.orig</tt> directory to
+ <tt><var>package</var>-<var>version</var></tt>.</p>
+ </item>
+ <item>
+ <p>
+ Create the subdirectory <tt>debian</tt> at the top of
+ the source tree.</p>
+ </item>
+ <item><p>Apply the diff using <tt>patch -p0</tt>.</p>
+ </item>
+ <item><p>Untar the tarfile again if you want a copy of the original
+ source code alongside the Debianised version.</p>
+ </item>
+ </enumlist>
+
+ <p>
+ It is not possible to generate a valid Debian source archive
+ without using <prgn>dpkg-source</prgn>. In particular,
+ attempting to use <prgn>diff</prgn> directly to generate the
+ <tt>.diff.gz</tt> file will not work.
+ </p>
+
+ <sect1><heading>Restrictions on objects in source packages
+ </heading>
+
+ <p>
+ The source package may not contain any hard links
+ <footnote>
+ <p>
+ This is not currently detected when building source
+ packages, but only when extracting
+ them.
+ </p>
+ </footnote>
+ <footnote>
+ <p>
+ Hard links may be permitted at some point in the
+ future, but would require a fair amount of
+ work.
+ </p>
+ </footnote>, device special files, sockets or setuid or
+ setgid files.
+ <footnote>
+ <p>
+ Setgid directories are allowed.
+ </p>
+ </footnote>
+ </p>
+
+ <p>
+ The source packaging tools manage the changes between the
+ original and Debianised source using <prgn>diff</prgn> and
+ <prgn>patch</prgn>. Turning the original source tree as
+ included in the <tt>.orig.tar.gz</tt> into the debianised
+ source must not involve any changes which cannot be
+ handled by these tools. Problematic changes which cause
+ <prgn>dpkg-source</prgn> to halt with an error when
+ building the source package are:
+ <list compact="compact">
+ <item><p>Adding or removing symbolic links, sockets or pipes.</p>
+ </item>
+ <item><p>Changing the targets of symbolic links.</p>
+ </item>
+ <item><p>Creating directories, other than <tt>debian</tt>.</p>
+ </item>
+ <item><p>Changes to the contents of binary files.</p></item>
+ </list> Changes which cause <prgn>dpkg-source</prgn> to
+ print a warning but continue anyway are:
+ <list compact="compact">
+ <item>
+ <p>
+ Removing files, directories or symlinks.
+ <footnote>
+ <p>
+ Renaming a file is not treated specially - it is
+ seen as the removal of the old file (which
+ generates a warning, but is otherwise ignored),
+ and the creation of the new
+ one.</p>
+ </footnote>
+ </p>
+ </item>
+ <item>
+ <p>
+ Changed text files which are missing the usual final
+ newline (either in the original or the modified
+ source tree).
+ </p>
+ </item>
+ </list>
+ Changes which are not represented, but which are not detected by
+ <prgn>dpkg-source</prgn>, are:
+ <list compact="compact">
+ <item><p>Changing the permissions of files (other than
+ <tt>debian/rules</tt>) and directories.</p></item>
+ </list>
+ </p>
+
+ <p>
+ The <tt>debian</tt> directory and <tt>debian/rules</tt>
+ are handled specially by <prgn>dpkg-source</prgn> - before
+ applying the changes it will create the <tt>debian</tt>
+ directory, and afterwards it will make
+ <tt>debian/rules</tt> world-exectuable.
+ </p>
+ </sect1>
+ </sect>
+ </appendix>
+
+ <appendix id="pkg-controlfields"><heading>Control files and their
+ fields (from old Packaging Manual)
+ </heading>
+
+ <p>
+ Many of the tools in the <prgn>dpkg</prgn> suite manipulate
+ data in a common format, known as control files. Binary and
+ source packages have control data as do the <tt>.changes</tt>
+ files which control the installation of uploaded files, and
+ <prgn>dpkg</prgn>'s internal databases are in a similar
+ format.
+ </p>
+
+ <sect><heading>Syntax of control files
+ </heading>
+
+ <p>
+ A file consists of one or more paragraphs of fields. The
+ paragraphs are separated by blank lines. Some control files
+ only allow one paragraph; others allow several, in which
+ case each paragraph often refers to a different package.
+ </p>
+
+ <p>
+ Each paragraph is a series of fields and values; each field
+ consists of a name, followed by a colon and the value. It
+ ends at the end of the line. Horizontal whitespace (spaces
+ and tabs) may occur before or after the value and is ignored
+ there; it is conventional to put a single space after the
+ colon.
+ </p>
+
+ <p>
+ Some fields' values may span several lines; in this case
+ each continuation line <em>must</em> start with a space or
+ tab. Any trailing spaces or tabs at the end of individual
+ lines of a field value are ignored.
+ </p>
+
+ <p>
+ Except where otherwise stated only a single line of data is
+ allowed and whitespace is not significant in a field body.
+ Whitespace may never appear inside names (of packages,
+ architectures, files or anything else), version numbers or
+ in between the characters of multi-character version
+ relationships.
+ </p>
+
+ <p>
+ Field names are not case-sensitive, but it is usual to
+ capitalise the field names using mixed case as shown below.
+ </p>
+
+ <p>
+ Blank lines, or lines consisting only of spaces and tabs,
+ are not allowed within field values or between fields - that
+ would mean a new paragraph.
+ </p>
+
+ <p>
+ It is important to note that there are several fields which
+ are optional as far as <prgn>dpkg</prgn> and the related
+ tools are concerned, but which must appear in every Debian
+ package, or whose omission may cause problems. When writing
+ the control files for Debian packages you <em>must</em> read
+ the Debian policy manual in conjuction with the details
+ below and the list of fields for the particular file.</p>
+ </sect>
+
+ <sect><heading>List of fields
+ </heading>
+
+ <sect1 id="pkg-f-Package"><heading><tt>Package</tt>
+ </heading>
+
+ <p>
+ The name of the binary package. Package names consist of
+ the alphanumerics and <tt>+</tt> <tt>-</tt> <tt>.</tt>
+ (plus, minus and full stop).
+ <footnote>
+ <p>
+ The characters <tt>@</tt> <tt>:</tt> <tt>=</tt>
+ <tt>%</tt> <tt>_</tt> (at, colon, equals, percent
+ and underscore) used to be legal and are still
+ accepted when found in a package file, but may not be
+ used in new packages
+ </p>
+ </footnote>
+ </p>
+
+ <p>
+ They must be at least two characters and must start with
+ an alphanumeric. In current versions of dpkg they are
+ sort of case-sensitive<footnote><p>This is a
+ bug.</p></footnote>; use lowercase package names unless
+ the package you're building (or referring to, in other
+ fields) is already using uppercase.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Version"><heading><tt>Version</tt>
+ </heading>
+
+ <p>
+ This lists the source or binary package's version number -
+ see <ref id="versions">.
+ </p>
+
+ </sect1>
+
+ <sect1 id="pkg-f-Architecture"><heading><tt>Architecture</tt>
+ </heading>
+
+ <p>
+ This is the architecture string; it is a single word for
+ the Debian architecture.
+ </p>
+
+ <p>
+ <prgn>dpkg</prgn> will check the declared architecture of
+ a binary package against its own compiled-in value before
+ it installs it.
+ </p>
+
+ <p>
+ The special value <tt>all</tt> indicates that the package
+ is architecture-independent.
+ </p>
+
+ <p>
+ In the main <tt>debian/control</tt> file in the source
+ package, or in the source package control file
+ <tt>.dsc</tt>, a list of architectures (separated by
+ spaces) is also allowed, as is the special value
+ <tt>any</tt>. A list indicates that the source will build
+ an architecture-dependent package, and will only work
+ correctly on the listed architectures. <tt>any</tt>
+ indicates that though the source package isn't dependent
+ on any particular architecture and should compile fine on
+ any one, the binary package(s) produced are not
+ architecture-independent but will instead be specific to
+ whatever the current build architecture is.
+ </p>
+
+ <p>
+ In a <tt>.changes</tt> file the <tt>Architecture</tt>
+ field lists the architecture(s) of the package(s)
+ currently being uploaded. This will be a list; if the
+ source for the package is being uploaded too the special
+ entry <tt>source</tt> is also present.
+ </p>
+
+ <p>
+ See <ref id="pkg-debianrules"> for information how to get the
+ architecture for the build process.
+ </p>
+ </sect1>
+
+ <sect1 id="pkg-f-Maintainer"><heading><tt>Maintainer</tt>
+ </heading>
+
+ <p>
+ The package maintainer's name and email address. The name
+ should come first, then the email address inside angle
+ brackets <tt><></tt> (in RFC822 format).
+ </p>
+
+ <p>
+ If the maintainer's name contains a full stop then the
+ whole field will not work directly as an email address due
+ to a misfeature in the syntax specified in RFC822; a
+ program using this field as an address must check for this
+ and correct the problem if necessary (for example by
+ putting the name in round brackets and moving it to the
+ end, and bringing the email address forward).
+ </p>
+
+ <p>
+ In a <tt>.changes</tt> file or parsed changelog data this
+ contains the name and email address of the person
+ responsible for the particular version in question - this
+ may not be the package's usual maintainer.
+ </p>
+
+ <p>
+ This field is usually optional in as far as the
+ <prgn>dpkg</prgn> are concerned, but its absence when
+ building packages usually generates a warning.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Source"><heading><tt>Source</tt>
+ </heading>
+
+ <p>
+ This field identifies the source package name.
+ </p>
+
+ <p>
+ In a main source control information or a
+ <tt>.changes</tt> or <tt>.dsc</tt> file or parsed
+ changelog data this may contain only the name of the
+ source package.
+ </p>
+
+ <p>
+ In the control file of a binary package (or in a
+ <tt>Packages</tt> file) it may be followed by a version
+ number in parentheses.
+ <footnote>
+ <p>
+ It is usual to leave a space after the package name if
+ a version number is specified.
+ </p>
+ </footnote> This version number may be omitted (and is, by
+ <prgn>dpkg-gencontrol</prgn>) if it has the same value as
+ the <tt>Version</tt> field of the binary package in
+ question. The field itself may be omitted from a binary
+ package control file when the source package has the same
+ name and version as the binary package.
+ </p>
+ </sect1>
+
+ <sect1><heading>Package interrelationship fields:
+ <tt>Depends</tt>, <tt>Pre-Depends</tt>,
+ <tt>Recommends</tt> <tt>Suggests</tt>, <tt>Conflicts</tt>,
+ <tt>Provides</tt>, <tt>Replaces</tt>
+ </heading>
+
+ <p>
+ These fields describe the package's relationships with
+ other packages. Their syntax and semantics are described
+ in <ref id="relationships">.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Description"><heading><tt>Description</tt>
+ </heading>
+
+ <p>
+ In a binary package <tt>Packages</tt> file or main source
+ control file this field contains a description of the
+ binary package, in a special format. See <ref
+ id="descriptions"> for details.
+ </p>
+
+ <p>
+ In a <tt>.changes</tt> file it contains a summary of the
+ descriptions for the packages being uploaded. 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="pkg-f-Essential"><heading><tt>Essential</tt>
+ </heading>
+
+ <p>
+ This is a boolean field which may occur only in the
+ control file of a binary package (or in the
+ <tt>Packages</tt> file) or in a per-package fields
+ paragraph of a main source control data file.
+ </p>
+
+ <p>
+ If set to <tt>yes</tt> then <prgn>dpkg</prgn> and
+ <prgn>dselect</prgn> will refuse to remove the package
+ (though it can be upgraded and/or replaced). The other
+ possible value is <tt>no</tt>, which is the same as not
+ having the field at all.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-classification"><heading><tt>Section</tt> and
+ <tt>Priority</tt>
+ </heading>
+
+ <p>
+ These two fields classify the package. The
+ <tt>Priority</tt> represents how important that it is that
+ the user have it installed; the <tt>Section</tt>
+ represents an application area into which the package has
+ been classified.
+ </p>
+
+ <p>
+ When they appear in the <tt>debian/control</tt> file these
+ fields give values for the section and priority subfields
+ of the <tt>Files</tt> field of the <tt>.changes</tt> file,
+ and give defaults for the section and priority of the
+ binary packages.
+ </p>
+
+ <p>
+ The section and priority are represented, though not as
+ separate fields, in the information for each file in the
+ <qref id="pkg-f-Files"><tt>-File</tt></qref>field of a
+ <tt>.changes</tt> file. The section value in a
+ <tt>.changes</tt> file is used to decide where to install
+ a package in the FTP archive.
+ </p>
+
+ <p>
+ These fields are not used by by <prgn>dpkg</prgn> proper,
+ but by <prgn>dselect</prgn> when it sorts packages and
+ selects defaults. See the Debian policy manual for the
+ priorities in use and the criteria for selecting the
+ priority for a Debian package, and look at the Debian FTP
+ archive for a list of currently in-use priorities.
+ </p>
+
+ <p>
+ These fields may appear in binary package control files,
+ in which case they provide a default value in case the
+ <tt>Packages</tt> files are missing the information.
+ <prgn>dpkg</prgn> and <prgn>dselect</prgn> will only use
+ the value from a <tt>.deb</tt> file if they have no other
+ information; a value listed in a <tt>Packages</tt> file
+ will always take precedence. By default
+ <prgn>dpkg-gencontrol</prgn> does not include the section
+ and priority in the control file of a binary package - use
+ the <tt>-isp</tt>, <tt>-is</tt> or <tt>-ip</tt> options to
+ achieve this effect.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Binary"><heading><tt>Binary</tt>
+ </heading>
+
+ <p>
+ This field is a list of binary packages.
+ </p>
+
+ <p>
+ When it appears in the <tt>.dsc</tt> 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 <tt>.changes</tt> file it lists the
+ names of the binary packages actually being uploaded.
+ </p>
+
+ <p>
+ The syntax is a list of binary packages separated by
+ commas.
+ <footnote>
+ <p>
+ A space after each comma is conventional.
+ </p>
+ </footnote> Currently the packages must be separated using
+ only spaces in the <tt>.changes</tt> file.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Installed-Size"><heading><tt>Installed-Size</tt>
+ </heading>
+
+ <p>
+ This field appears in the control files of binary
+ packages, and in the <tt>Packages</tt> files. It gives
+ the total amount of disk space required to install the
+ named package.
+ </p>
+
+ <p>
+ The disk space is represented in kilobytes as a simple
+ decimal number.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Files"><heading><tt>Files</tt>
+ </heading>
+
+ <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 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.
+ </p>
+
+ <p>
+ In the <tt>.dsc</tt> (Debian source control) file each
+ line contains the MD5 checksum, size and filename of the
+ tarfile and (if applicable) diff file which make up the
+ remainder of the source package.
+ <footnote>
+ <p>
+ That is, the parts which are not the
+ <tt>.dsc</tt>.
+ </p>
+ </footnote> The exact forms of the filenames are described
+ in <ref id="pkg-sourcearchives">.
+ </p>
+
+ <p>
+ In the <tt>.changes</tt> file this contains one line per
+ file being uploaded. Each line contains the MD5 checksum,
+ size, section and priority and the filename. The section
+ and priority are the values of the corresponding fields in
+ the main source control file - see <ref
+ id="pkg-f-classification">. 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>
+ The special value <tt>byhand</tt> for the section in a
+ <tt>.changes</tt> file indicates that the file in question
+ is not an ordinary package file and must by installed by
+ hand by the distribution maintainers. If the section is
+ <tt>byhand</tt> the priority should be <tt>-</tt>.
+ </p>
+
+ <p>
+ If a new Debian revision of a package is being shipped and
+ no new original source archive is being distributed the
+ <tt>.dsc</tt> must still contain the <tt>Files</tt> field
+ entry for the original source archive
+ <tt><var>package</var>-<var>upstream-version</var>.orig.tar.gz</tt>,
+ but the <tt>.changes</tt> file should leave it out. In
+ this case the original source archive on the distribution
+ site must match exactly, byte-for-byte, the original
+ source archive which was used to generate the
+ <tt>.dsc</tt> file and diff which are being uploaded.</p>
+ </sect1>
+
+
+ <sect1
+ id="pkg-f-Standards-Version"><heading><tt>Standards-Version</tt>
+ </heading>
+
+ <p>
+ The most recent version of the standards (the
+ <prgn>dpkg</prgn> programmers' and policy manuals and
+ associated texts) with which the package complies. This
+ is updated manually when editing the source package to
+ conform to newer standards; it can sometimes be used to
+ tell when a package needs attention.
+ </p>
+
+ <p>
+ Its format is the same as that of a version number except
+ that no epoch or Debian revision is allowed - see <ref
+ id="versions">.</p>
+ </sect1>
+
+
+ <sect1 id="pkg-f-Distribution"><heading><tt>Distribution</tt>
+ </heading>
+
+ <p>
+ In a <tt>.changes</tt> file or parsed changelog output
+ this contains the (space-separated) name(s) of the
+ distribution(s) where this version of the package should
+ be or was installed. Distribution names follow the rules
+ for package names. (See <ref id="pkg-f-Package">).
+ </p>
+
+ <p>
+ Current distribution values are:
+ <taglist>
+ <tag><em>stable</em></tag>
+ <item>
+ <p>
+ This is the current `released' version of Debian
+ GNU/Linux. A new version is released approximately
+ every 3 months after the <em>development</em> code has
+ been <em>frozen</em> for a month of testing. Once the
+ distribution is <em>stable</em> only major bug fixes
+ are allowed. When changes are made to this
+ distribution, the release number is increased
+ (for example: 1.2r1 becomes 1.2r2 then 1.2r3, etc).
+ </p>
+ </item>
+
+ <tag><em>unstable</em></tag>
+ <item>
+ <p>
+ This distribution value refers to the
+ <em>developmental</em> part of the Debian distribution
+ tree. New packages, new upstream versions of packages
+ and bug fixes go into the <em>unstable</em> directory
+ tree. Download from this distribution at your own
+ risk.</p>
+ </item>
+
+ <tag><em>contrib</em></tag>
+ <item>
+ <p>
+ The packages with this distribution value do not meet
+ the criteria for inclusion in the main Debian
+ distribution as defined by the Policy Manual, but meet
+ the criteria for the <em>contrib</em>
+ Distribution. There is currently no distinction
+ between stable and unstable packages in the
+ <em>contrib</em> or <em>non-free</em>
+ distributions. Use your best judgement in downloading
+ from this Distribution.</p>
+ </item>
+
+ <tag><em>non-free</em></tag>
+ <item>
+ <p>
+ Like the packages in the <em>contrib</em> seciton,
+ the packages in <em>non-free</em> do not meet the
+ criteria for inclusion in the main Debian distribution
+ as defined by the Policy Manual. Again, use your best
+ judgement in downloading from this Distribution.</p>
+
+ <tag><em>experimental</em></tag>
+ <item>
+ <p>
+ The packages with this distribution value are deemed
+ by their maintainers to be high risk. Oftentimes they
+ represent early beta or developmental packages from
+ various sources that the maintainers want people to
+ try, but are not ready to be a part of the other parts
+ of the Debian distribution tree. Download at your own
+ risk.</p>
+ </item>
+
+ <tag><em>frozen</em></tag>
+ <item>
+ <p>
+ From time to time, (currently, every 3 months) the
+ <em>unstable</em> distribution enters a state of
+ `code-freeze' in anticipation of release as a
+ <em>stable</em> version. During this period of testing
+ (usually 4 weeks) only fixes for existing or
+ newly-discovered bugs will be allowed.
+ </p>
+ </item>
+ </taglist> You should list <em>all</em> distributions that
+ the package should be installed into. Except in unusual
+ circumstances, installations to <em>stable</em> should also
+ go into <em>frozen</em> (if it exists) and
+ <em>unstable</em>. Likewise, installations into
+ <em>frozen</em> should also go into <em>unstable</em>.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Urgency"><heading><tt>Urgency</tt>
+ </heading>
+
+ <p>
+ This is a description of how important it is to upgrade to
+ this version from previous ones. It consists of a single
+ keyword usually taking one of the values <tt>LOW</tt>,
+ <tt>MEDIUM</tt> or <tt>HIGH</tt>) followed by an optional
+ commentary (separated by a space) which is usually in
+ parentheses. For example:
+ <example>
+ Urgency: LOW (HIGH for diversions users)
+ </example>
+ </p>
+
+ <p>
+ This field appears in the <tt>.changes</tt> file and in
+ parsed changelogs; its value appears as the value of the
+ <tt>urgency</tt> attribute in a <prgn>dpkg</prgn>-style
+ changelog (see <ref id="pkg-dpkgchangelog">).
+ </p>
+
+ <p>
+ Urgency keywords are not case-sensitive.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Date"><heading><tt>Date</tt>
+ </heading>
+
+ <p>
+ In <tt>.changes</tt> files and parsed changelogs, this
+ gives the date the package was built or last edited.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Format"><heading><tt>Format</tt>
+ </heading>
+
+ <p>
+ This field occurs in <tt>.changes</tt> files, and
+ specifies a format revision for the file. The format
+ described here is version <tt>1.5</tt>. The syntax of the
+ format value is the same as that of a package version
+ number except that no epoch or Debian revision is allowed
+ - see <ref id="versions">.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Changes"><heading><tt>Changes</tt>
+ </heading>
+
+ <p>
+ In a <tt>.changes</tt> file or parsed changelog this field
+ contains the human-readable changes data, describing the
+ differences between the last version and the current one.
+ </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
+ consiting only of a space and a full stop.
+ </p>
+
+ <p>
+ Each version's change information should be preceded by a
+ `title' line giving at least the version, distribution(s)
+ and urgency, in a human-readable way.
+ </p>
+
+ <p>
+ If data from several versions is being returned the entry
+ for the most recent version should be returned first, and
+ entries should be separated by the representation of a
+ blank line (the `title' line may also be followed by the
+ representation of blank line).</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Filename"><heading><tt>Filename</tt> and
+ <tt>MSDOS-Filename</tt>
+ </heading>
+
+ <p>
+ These fields in <tt>Packages</tt> files give the
+ filename(s) of (the parts of) a package in the
+ distribution directories, relative to the root of the
+ Debian hierarchy. If the package has been split into
+ several parts the parts are all listed in order, separated
+ by spaces.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Size"><heading><tt>Size</tt> and <tt>MD5sum</tt>
+ </heading>
+
+ <p>
+ These fields in <tt>Packages</tt> files give the size (in
+ bytes, expressed in decimal) and MD5 checksum of the
+ file(s) which make(s) up a binary package in the
+ distribution. If the package is split into several parts
+ the values for the parts are listed in order, separated by
+ spaces.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Status"><heading><tt>Status</tt>
+ </heading>
+
+ <p>
+ This field in <prgn>dpkg</prgn>'s status file records
+ whether the user wants a package installed, removed or
+ left alone, whether it is broken (requiring
+ reinstallation) or not and what its current state on the
+ system is. Each of these pieces of information is a
+ single word.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Config-Version"><heading><tt>Config-Version</tt>
+ </heading>
+
+ <p>
+ If a package is not installed or not configured, this
+ field in <prgn>dpkg</prgn>'s status file records the last
+ version of the package which was successfully
+ configured.</p>
+ </sect1>
+
+ <sect1 id="pkg-f-Conffiles"><heading><tt>Conffiles</tt>
+ </heading>
+
+ <p>
+ This field in <prgn>dpkg</prgn>'s status file contains
+ information about the automatically-managed configuration
+ files held by a package. This field should <em>not</em>
+ appear anywhere in a package!</p>
+ </sect1>
+
+ <sect1><heading>Obsolete fields
+ </heading>
+
+ <p>
+ These are still recognised by <prgn>dpkg</prgn> but should
+ not appear anywhere any more.
+ <taglist compact="compact">
+
+ <tag><tt>Revision</tt></tag>
+ <tag><tt>Package-Revision</tt></tag>
+ <tag><tt>Package_Revision</tt></tag>
+ <item>
+ <p>
+ The Debian revision part of the package version was
+ at one point in a separate control file field. This
+ field went through several names.</p>
+ </item>
+
+ <tag><tt>Recommended</tt></tag>
+ <item><p>Old name for <tt>Recommends</tt></p>
+ </item>
+
+ <tag><tt>Optional</tt></tag>
+ <item><p>Old name for <tt>Suggests</tt>.</p>
+ </item>
+ <tag><tt>Class</tt></tag>
+ <item><p>Old name for <tt>Priority</tt>.</p>
+ </item>
+ </taglist>
+ </p>
+ </sect1>
+ </sect>
+ </appendix>
+
+ <appendix id="pkg-conffiles"><heading>Configuration file handling
+ (from old Packaging Manual)
+ </heading>
+
+ <p>
+ <prgn>dpkg</prgn> can do a certain amount of automatic
+ handling of package configuration files.
+ </p>
+
+ <p>
+ Whether this mechanism is appropriate depends on a number of
+ factors, but basically there are two approaches to any
+ particular configuration file.
+ </p>
+
+ <p>
+ The easy method is to ship a best-effort configuration in the
+ package, and use <prgn>dpkg</prgn>'s conffile mechanism to
+ handle updates. If the user is unlikely to want to edit the
+ file, but you need them to be able to without losing their
+ changes, and a new package with a changed version of the file
+ is only released infrequently, this is a good approach.
+ </p>
+
+ <p>
+ The hard method is to build the configuration file from
+ scratch in the <prgn>postinst</prgn> script, and to take the
+ responsibility for fixing any mistakes made in earlier
+ versions of the package automatically. This will be
+ appropriate if the file is likely to need to be different on
+ each system.
+ </p>
+
+ <sect><heading>Automatic handling of configuration files by
+ <prgn>dpkg</prgn>
+ </heading>
+
+ <p>
+ A package may contain a control area file called
+ <tt>conffiles</tt>. This file should be a list of filenames
+ of configuration files needing automatic handling, separated
+ by newlines. The filenames should be absolute pathnames,
+ and the files referred to should actually exist in the
+ package.
+ </p>
+
+ <p>
+ When a package is upgraded <prgn>dpkg</prgn> will process
+ the configuration files during the configuration stage,
+ shortly before it runs the package's <prgn>postinst</prgn>
+ script,
+ </p>
+
+ <p>
+ For each file it checks to see whether the version of the
+ file included in the package is the same as the one that was
+ included in the last version of the package (the one that is
+ being upgraded from); it also compares the version currently
+ installed on the system with the one shipped with the last
+ version.
+ </p>
+
+ <p>
+ If neither the user nor the package maintainer has changed
+ the file, it is left alone. If one or the other has changed
+ their version, then the changed version is preferred - i.e.,
+ if the user edits their file, but the package maintainer
+ doesn't ship a different version, the user's changes will
+ stay, silently, but if the maintainer ships a new version
+ and the user hasn't edited it the new version will be
+ installed (with an informative message). If both have
+ changed their version the user is prompted about the problem
+ and must resolve the differences themselves.
+ </p>
+
+ <p>
+ The comparisons are done by calculating the MD5 message
+ digests of the files, and storing the MD5 of the file as it
+ was included in the most recent version of the package.
+ </p>
+
+ <p>
+ When a package is installed for the first time
+ <prgn>dpkg</prgn> will install the file that comes with it,
+ unless that would mean overwriting a file already on the
+ filesystem.
+ </p>
+
+ <p>
+ However, note that <prgn>dpkg</prgn> will <em>not</em>
+ replace a conffile that was removed by the user (or by a
+ script). This is necessary because with some programs a
+ missing file produces an effect hard or impossible to
+ achieve in another way, so that a missing file needs to be
+ kept that way if the user did it.
+ </p>
+
+ <p>
+ Note that a package should <em>not</em> modify a
+ <prgn>dpkg</prgn>-handled conffile in its maintainer
+ scripts. Doing this will lead to <prgn>dpkg</prgn> giving
+ the user confusing and possibly dangerous options for
+ conffile update when the package is upgraded.</p>
+ </sect>
+
+ <sect><heading>Fully-featured maintainer script configuration
+ handling
+ </heading>
+
+ <p>
+ For files which contain site-specific information such as
+ the hostname and networking details and so forth, it is
+ better to create the file in the package's
+ <prgn>postinst</prgn> script.
+ </p>
+
+ <p>
+ This will typically involve examining the state of the rest
+ of the system to determine values and other information, and
+ may involve prompting the user for some information which
+ can't be obtained some other way.
+ </p>
+
+ <p>
+ When using this method there are a couple of important
+ issues which should be considered:
+ </p>
+
+ <p>
+ If you discover a bug in the program which generates the
+ configuration file, or if the format of the file changes
+ from one version to the next, you will have to arrange for
+ the postinst script to do something sensible - usually this
+ will mean editing the installed configuration file to remove
+ the problem or change the syntax. You will have to do this
+ very carefully, since the user may have changed the file,
+ perhaps to fix the very problem that your script is trying
+ to deal with - you will have to detect these situations and
+ deal with them correctly.
+ </p>
+
+ <p>
+ If you do go down this route it's probably a good idea to
+ make the program that generates the configuration file(s) a
+ separate program in <tt>/usr/sbin</tt>, by convention called
+ <tt><var>package</var>config</tt> and then run that if
+ appropriate from the post-installation script. The
+ <tt><var>package</var>config</tt> program should not
+ unquestioningly overwrite an existing configuration - if its
+ mode of operation is geared towards setting up a package for
+ the first time (rather than any arbitrary reconfiguration
+ later) you should have it check whether the configuration
+ already exists, and require a <tt>--force</tt> flag to
+ overwrite it.</p></sect>
+ </appendix>
+
+ <appendix id="pkg-alternatives"><heading>Alternative versions of
+ an interface - <prgn>update-alternatives</prgn> (from old
+ Packaging Manual)
+ </heading>
+
+ <p>
+ When several packages all provide different versions of the
+ same program or file it is useful to have the system select a
+ default, but to allow the system administrator to change it
+ and have their decisions respected.
+ </p>
+
+ <p>
+ For example, there are several versions of the <prgn>vi</prgn>
+ editor, and there is no reason to prevent all of them from
+ being installed at once, each under their own name
+ (<prgn>nvi</prgn>, <prgn>vim</prgn> or whatever).
+ Nevertheless it is desirable to have the name <tt>vi</tt>
+ refer to something, at least by default.
+ </p>
+
+ <p>
+ If all the packages involved cooperate, this can be done with
+ <prgn>update-alternatives</prgn>.
+ </p>
+
+ <p>
+ Each package provides its own version under its own name, and
+ calls <prgn>update-alternatives</prgn> in its postinst to
+ register its version (and again in its prerm to deregister
+ it).
+ </p>
+
+ <p>
+ See the manpage <manref name="update-alternatives"
+ section="8"> for details.
+ </p>
+
+ <p>
+ If <prgn>update-alternatives</prgn> does not seem appropriate
+ you may wish to consider using diversions instead.</p>
+ </appendix>
+
+ <appendix id="pkg-diversions"><heading>Diversions - overriding a
+ package's version of a file (from old Packaging Manual)
+ </heading>
+
+ <p>
+ It is possible to have <prgn>dpkg</prgn> not overwrite a file
+ when it reinstalls the package it belongs to, and to have it
+ put the file from the package somewhere else instead.
+ </p>
+
+ <p>
+ This can be used locally to override a package's version of a
+ file, or by one package to override another's version (or
+ provide a wrapper for it).
+ </p>
+
+ <p>
+ Before deciding to use a diversion, read <ref
+ id="pkg-alternatives"> to see if you really want a diversion
+ rather than several alternative versions of a program.
+ </p>
+
+ <p>
+ There is a diversion list, which is read by <prgn>dpkg</prgn>,
+ and updated by a special program <prgn>dpkg-divert</prgn>.
+ Please see <manref name="dpkg-divert" section="8"> for full
+ details of its operation.
+ </p>
+
+ <p>
+ When a package wishes to divert a file from another, it should
+ call <prgn>dpkg-divert</prgn> in its preinst to add the
+ diversion and rename the existing file. For example,
+ supposing that a <prgn>smailwrapper</prgn> package wishes to
+ install a wrapper around <tt>/usr/sbin/smail</tt>:
+ <example>
+ if [ install = "$1" -o upgrade = "$1" ]; then
+ dpkg-divert --package smailwrapper --add --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ </example> Testing <tt>$1</tt> is necessary so that the script
+ doesn't try to add the diversion again when
+ <prgn>smailwrapper</prgn> is upgraded. The <tt>--package
+ smailwrapper</tt> ensures that <prgn>smailwrapper</prgn>'s
+ copy of <tt>/usr/sbin/smail</tt> can bypass the diversion and
+ get installed as the true version.
+ </p>
+
+ <p>
+ The postrm has to do the reverse:
+ <example>
+ if [ remove = "$1" ]; then
+ dpkg-divert --package smailwrapper --remove --rename \
+ --divert /usr/sbin/smail.real /usr/sbin/smail
+ fi
+ </example>
+ </p>
+
+ <p>
+ Do not attempt to divert a file which is vitally important for
+ the system's operation - when using <prgn>dpkg-divert</prgn>
+ there is a time, after it has been diverted but before
+ <prgn>dpkg</prgn> has installed the new version, when the file
+ does not exist.</p>
+ </appendix>
+
</book>
</debiandoc>
projects / debian / debian-policy.git / blobdiff