12.1. Manual pages¶
You should install manual pages in
nroff source form, in appropriate
/usr/share/man. You should only use sections 1 to 9
(see the FHS for more details). You must not install a pre-formatted
Each program, utility, and function should have an associated manual page included in the same package or a dependency. It is suggested that all configuration files also have a manual page included as well. Manual pages for protocols and other auxiliary things are optional.
If no manual page is available, this is considered as a bug and should be reported to the Debian Bug Tracking System (the maintainer of the package is allowed to write this bug report themselves, if they so desire). Do not close the bug report until a proper man page is available. 1
You may forward a complaint about a missing man page to the upstream authors, and mark the bug as forwarded in the Debian bug tracking system. Even though the GNU Project do not in general consider the lack of a man page to be a bug, we do; if they tell you that they don’t consider it a bug you should leave the bug in our bug tracking system open anyway.
Manual pages should be installed compressed using
If one man page needs to be accessible via several names it is better to
use a symbolic link than the
.so feature, but there is no need to
fiddle with the relevant parts of the upstream source to change from
.so to symlinks: don’t do it unless it’s easy. You should not create
hard links in the manual page directories, nor put absolute filenames in
.so directives. The filename in a
.so in a man page should be
relative to the base of the man page tree (usually
If you do not create any links (whether symlinks, hard links, or
directives) in the file system to the alternate names of the man page,
then you should not rely on
man finding your man page under those
names based solely on the information in the man page’s header. 2
Manual pages in locale-specific subdirectories of
should use either UTF-8 or the usual legacy encoding for that language
(normally the one corresponding to the shortest relevant locale name in
/usr/share/i18n/SUPPORTED). For example, pages under
/usr/share/man/fr should use either UTF-8 or ISO-8859-1. 3
A country name (the
de_DE) should not be included in the
subdirectory name unless it indicates a significant difference in the
language, as this excludes speakers of the language in other countries.
If a localized version of a manual page is provided, it should either be up-to-date or it should be obvious to the reader that it is outdated and the original manual page should be used instead. This can be done either by a note at the beginning of the manual page or by showing the missing or changed portions in the original language instead of the target language.
12.2. Info documents¶
Info documents should be installed in
/usr/share/info. They should
be compressed with
install-info program maintains a directory of installed info
/usr/share/info/dir for the use of info readers. This
file must not be included in packages other than install-info.
install-info is automatically invoked when appropriate using dpkg
triggers. Packages other than install-info should not invoke
install-info directly and should not depend on, recommend, or
suggest install-info for this purpose.
Info readers requiring the
/usr/share/info/dir file should depend on
Info documents should contain section and directory entry information in
the document for the use of
install-info. The section should be
specified via a line starting with
INFO-DIR-SECTION followed by a
space and the section of this info page. The directory entry or entries
should be included between a
START-INFO-DIR-ENTRY line and an
END-INFO-DIR-ENTRY line. For example:
INFO-DIR-SECTION Individual utilities START-INFO-DIR-ENTRY * example: (example). An example info directory entry. END-INFO-DIR-ENTRY
To determine which section to use, you should look at
/usr/share/info/dir on your system and choose the most relevant (or
create a new section if none of the current sections are relevant).
12.3. Additional documentation¶
Any additional documentation that comes with the package may be
installed at the discretion of the package maintainer. It is often a
good idea to include text information files (
READMEs, FAQs, and so
forth) that come with the source package in the binary package. However,
you don’t need to install the instructions for building and installing
the package, of course!
Plain text documentation should be compressed with
gzip -9 unless it is small.
If a package comes with large amounts of documentation that many users of the package will not require, you should create a separate binary package to contain it so that it does not take up disk space on the machines of users who do not need or want it installed. As a special case of this rule, shared library documentation of any appreciable size should always be packaged with the library development package (Development files) or in a separate documentation package, since shared libraries are frequently installed as dependencies of other packages by users who have little interest in documentation of the library itself. The documentation package for the package package is conventionally named package-doc (or package-doc-language-code if there are separate documentation packages for multiple languages).
If package is a build tool, development tool, command-line tool, or
library development package, package (or package-dev in the case of a
library development package) already provides documentation in man,
info, or plain text format, and package-doc provides HTML or other
formats, package should declare at most a
Suggests on package-doc.
Otherwise, package should declare at most a
Additional documentation included in the package should be installed
/usr/share/doc/package. If the documentation is packaged
separately, as package-doc for example, it may be installed under either
that path or into the documentation directory for the separate
documentation package (
/usr/share/doc/package-doc in this example).
However, installing the documentation into the documentation directory
of the main package is encouraged since it is independent of the
packaging method and will be easier for users to find.
Any separate package providing documentation must still install standard
documentation files in its own
/usr/share/doc directory as specified
in the rest of this policy. See, for example,
Copyright information and
Changelog files and release notes.
Packages must not require the existence of any files in
/usr/share/doc/ in order to function. 6 Any files that are
used or read by programs but are also useful as stand alone
documentation should be installed elsewhere, such as under
/usr/share/package/, and then included via symbolic links in
/usr/share/doc/package is permitted to be a symbolic link to another
/usr/share/doc only if the two packages both come from
the same source and the first package Depends on the second. Otherwise,
/usr/share/doc/package must not be a symbolic link. 7
12.4. Preferred documentation formats¶
The unification of Debian documentation is being carried out via HTML.
If the package comes with extensive documentation in a markup format that can be converted to various other formats you should if possible ship HTML versions in a binary package. 8 The documentation must be installed as specified in Additional documentation.
Other formats such as PostScript may be provided at the package maintainer’s discretion.
12.5. Copyright information¶
Every package must be accompanied by a verbatim copy of its
distribution license(s) in the file
This file must neither be compressed nor be a symbolic link.
A verbatim copy of the package’s copyright information is often
required to be present in
see Copyright considerations.
In addition, the copyright file must say where the upstream sources (if any) were obtained, and should include a name or contact address for the upstream authors. This can be the name of an individual or an organization, an email address, a web forum or bugtracker, or any other means to unambiguously identify who to contact to participate in the development of the upstream source code.
Packages in the contrib or non-free archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why.
A copy of the file which will be installed in
/usr/share/doc/PACKAGE/copyright should be in
in the source package.
/usr/share/doc/package is permitted be a symbolic link to another
/usr/share/doc only if the two packages both come from
the same source and the first package Depends on the second. Otherwise,
/usr/share/doc/package must not be a symbolic link. These rules are
copyright files must be extractable by mechanical
Packages distributed under the Apache license (version 2.0), the
Artistic license, the Creative Commons CC0-1.0 license, the GNU GPL
(versions 1, 2, or 3), the GNU LGPL (versions 2, 2.1, or 3), the GNU FDL
(versions 1.2 or 1.3), and the Mozilla Public License (version 1.1 or
2.0) should refer to the corresponding files under
/usr/share/common-licenses, 9 rather than quoting them in the
You should not use the copyright file as a general
README file. If
your package has such a file it should be installed in
README.Debian or some other
All copyright files must be encoded in UTF-8.
12.5.1. Machine-readable copyright information¶
A specification for a standard, machine-readable format for
debian/copyright files is maintained as part of the debian-policy
package. This document is in the
copyright-format files in the
debian-policy package. It is also available from the Debian web mirrors at
Use of this format is optional.
Any examples (configurations, source files, whatever), should be
installed in a directory
files should not be referenced by any program: they’re there for the
benefit of the system administrator and users as documentation only.
Architecture-specific example files should be installed in a directory
/usr/lib/package/examples with symbolic links to them from
/usr/share/doc/package/examples, or the latter directory itself may
be a symbolic link to the former.
If the purpose of a package is to provide examples, then the example
files may be installed into
12.7. Changelog files and release notes¶
Packages that are not Debian-native must contain a compressed copy of
debian/changelog file from the Debian source tree in
/usr/share/doc/package with the name
If an upstream release notes file is available, containing a summary
of changes between upstream releases intended for end users of the
package and often called
NEWS, it should be accessible as
/usr/share/doc/package/NEWS.gz. An older practice of installing
the upstream release notes as
is permitted but deprecated.
If there is an upstream changelog available, it may be made available
If either of these files are distributed in HTML, they should be made
/usr/share/doc/package/changelog.html.gz respectively, and plain
changelog.gz should be generated
from them, using, for example,
lynx -dump -nolist.
If the upstream release notes or changelog 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. 10
All of these files should be installed compressed using
gzip -9, as
they will become large with time even if they start out small.
If the package has only one file which is used both as the Debian
changelog and the upstream release notes or changelog, because there
is no separate upstream maintainer, then that file should usually be
/usr/share/doc/package/changelog.gz (depending on whether the file
is release notes or a changelog); if there is a separate upstream
maintainer, but no upstream release notes or changelog, then the
Debian changelog should still be called
For details about the format and contents of the Debian changelog file, please see Debian changelog: debian/changelog.
It is not very hard to write a man page. See the Man-Page-HOWTO, man(7), the examples created by
dh_make, the helper program
help2man, or the directory
Supporting this in
manoften 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 file system. This support is therefore deprecated and will cease to be present in the future.
manwill automatically detect whether UTF-8 is in use. In future, all manual pages will be required to use UTF-8.
At the time of writing, Chinese and Portuguese are the main languages with such differences, so
zh_TWare all allowed.
Normally, info documents are generated from Texinfo source. To include this information in the generated info document, if it is absent, add commands like:
@dircategory Individual utilities @direntry * example: (example). An example info directory entry. @end direntry
to the Texinfo source of the document and ensure that the info documents are rebuilt from source during the package build.
The system administrator should be able to delete files in
/usr/share/doc/without causing any programs to break.
Please note that this does not override the section on changelog files below, so the file
/usr/share/doc/package/changelog.Debian.gzmust refer to the changelog for the current version of package in question. In practice, this means that the sources of the target and the destination of the symlink must be the same (same source package and version).
Rationale: The important thing here is that HTML documentation should be available from some binary package.
/usr/share/common-licenses/MPL-2.0respectively. The University of California BSD license is also included in base-files as
/usr/share/common-licenses/BSD, but given the brevity of this license, its specificity to code whose copyright is held by the Regents of the University of California, and the frequency of minor wording changes, its text should be included in the copyright file rather than referencing this file.
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.