Debian's quality is largely due to the Debian Policy
, which
defines explicit baseline requirements which all Debian packages must fulfill.
Yet there is also a shared history of experience which goes beyond the Debian
Policy, an accumulation of years of experience in packaging. Many very
talented people have created great tools, tools which help you, the Debian
maintainer, create and maintain excellent packages.
This chapter provides some best practices for Debian developers. All recommendations are merely that, and are not requirements or policy. These are just some subjective hints, advice and pointers collected from Debian developers. Feel free to pick and choose whatever works best for you.
debian/rules
The following recommendations apply to the debian/rules
file.
Since debian/rules
controls the build process and selects the
files which go into the package (directly or indirectly), it's usually the file
maintainers spend the most time on.
The rationale for using helper scripts in debian/rules
is that
lets maintainers use and share common logic among many packages. Take for
instance the question of installing menu entries: you need to put the file into
/usr/lib/menu
, and add commands to the maintainer scripts to
register and unregister the menu entries. Since this is a very common thing
for packages to do, why should each maintainer rewrite all this on their own,
sometimes with bugs? Also, supposing the menu directory changed, every package
would have to be changed.
Helper scripts take care of these issues. Assuming you comply with the conventions expected by the helper script, the helper takes care of all the details. Changes in policy can be made in the helper script, then packages just need to be rebuilt with the new version of the helper and no other changes.
Overview of Debian Maintainer Tools, Appendix A
contains a couple of different helpers. The most common and best (in our
opinion) helper system is debhelper
. Previous helper systems,
such as debmake
, were "monolithic": you couldn't pick
and choose which part of the helper you found useful, but had to use the helper
to do everything. debhelper
, however, is a number of separate
little dh_*
programs. For instance, dh_installman
installs and compresses man pages, dh_installmenu
installs menu
files, and so on. Thus, it offers enough flexibility to be able to use the
little helper scripts, where useful, in conjunction with hand-crafted commands
in debian/rules
.
You can get started with debhelper
by reading
debhelper(1)
, and looking at the examples that come with the
package. dh_make
, from the dh-make
package (see dh-make
, Section A.3.3), can
be used to convert a "vanilla" source package to a
debhelper
ized package. This shortcut, though, should not convince
you that you do not need to bother understanding the individual
dh_*
helpers. If you are going to use a helper, you do need to
take the time to learn to use that helper, to learn its expectations and
behavior.
Some people feel that vanilla debian/rules
files are better, since
you don't have to learn the intricacies of any helper system. This decision is
completely up to you. Use what works for you. Many examples of vanilla
debian/rules
files are available at http://people.debian.org/~srivasta/rules/
.
Big, complex packages may have many bugs that you need to deal with. If you
correct a number of bug directly in the source, if you're not careful, it can
get hard to differentiate the various patches that you applied. It can get
quite messy when you have to update the package to a new upstream version which
integrates some of the fixes (but not all). You can't take the total set of
diffs (e.g., from .diff.gz
) and work out which patch sets to back
out as a unit as bugs are fixed upstream.
Unfortunately, the packaging system as such currently doesn't provide for
separating the patches into several files. Nevertheless, there are ways to
separate patches: the patch files are shipped within the Debian patch file
(.diff.gz
), usually within the debian/
directory.
The only difference is that they aren't applied immediately by dpkg-source, but
by the build rule of debian/rules
. Conversely, they
are reverted in the clean rule.
dbs
is one of the more popular approaches to this. It does all of
the above, and provides a facility for creating new and updating old patches.
See the package dbs
for more information and
hello-dbs
for an example.
dpatch
also provides these facilities, but it's intented to be
even easier to use. See the package dpatch
for documentation and
examples (in /usr/share/doc/dpatch
).
A single source package will often build several binary packages, either to
provide several flavors of the same software (e.g., the vim
source
package) or to make several small packages instead of a big one (e.g., if the
user can install only the subset she needs, and thus save some disk space).
The second case can be easily managed in debian/rules
. You just
need to move the appropriate files from the build directory into the package's
temporary trees. You can do this using install
or
dh_install
from debhelper
. Be sure to check the
different permutations of the various packages, ensuring that you have the
inter-package dependencies set right in debian/control
.
The first case is a bit more difficult since it involves multiple recompiles of
the same software but with different configuration options. The
vim
source package is an example of how to manage this using an
hand-crafted debian/rules
file.
debian/control
The following practices are relevant to the debian/control
file.
They supplement the Policy
on package descriptions
.
The description of the package, as defined by the corresponding field in the
control
file, contains both the package synopsis and the long
description for the package. General guidelines
for package descriptions, Section 6.2.1 describes common guidelines for
both parts of the package description. Following that, The package synopsis, or short description, Section
6.2.2 provides guidelines specific to the synopsis, and The long description, Section 6.2.3 contains
guidelines specific to the description.
The package description should be written for the average likely user, the average person who will use and benefit from the package. For instance, development packages are for developers, and can be technical in their language. More general-purpose applications, such as editors, should be written for a less technical user.
Our review of package descriptions lead us to conclude that most package descriptions are technical, that is, are not written to make sense for non-technical users. Unless your package really is only for technical users, this is a problem.
How do you write for non-technical users? Avoid jargon. Avoid referring to other applications or frameworks that the user might not be familiar with — "GNOME" or "KDE" is fine, since users are probably familiar with these terms, but "GTK+" is probably not. Try not to assume any knowledge at all. If you must use technical terms, introduce them.
Be objective. Package descriptions are not the place for advocating your package, no matter how much you love it. Remember that the reader may not care about the same things you care about.
References to the names of any other software packages, protocol names, standards, or specifications should use their canonical forms, if one exists. For example, use "X Window System", "X11", or "X"; not "X Windows", "X-Windows", or "X Window". Use "GTK+", not "GTK" or "gtk". Use "GNOME", not "Gnome". Use "PostScript", not "Postscript" or "postscript".
If you are having problems writing your description, you may wish to send it
along to debian-l10n-english@lists.debian.org
and request feedback.
The synopsis line (the short description) should be concise. It must not repeat the package's name (this is policy).
It's a good idea to think of the synopsis as an appositive clause, not a full sentence. An appositive clause is defined in WordNet as a grammatical relation between a word and a noun phrase that follows, e.g., "Rudolph the red-nosed reindeer". The appositive clause here is "red-nosed reindeer". Since the synopsis is a clause, rather than a full sentence, we recommend that it neither start with a capital nor end with a full stop (period). It should also not begin with an article, either definite ("the") or indefinite ("a" or "an").
It might help to imagine that the synopsis is combined with the package name in the following way:
package-name is a synopsis.
Alternatively, it might make sense to think of it as
package-name is synopsis.
or, if the package name itself is a plural (such as "developers-tools")
package-name are synopsis.
This way of forming a sentence from the package name and synopsis should be considered as a heuristic and not a strict rule. There are some cases where it doesn't make sense to try to form a sentence.
The long description is the primary information available to the user about a package before they install it. It should provide all the information needed to let the user decide whether to install the package. Assume that the user has already read the package synopsis.
The long description should consist of full and complete sentences.
The first paragraph of the long description should answer the following questions: what does the package do? what task does it help the user accomplish? It is important to describe this in a non-technical way, unless of course the audience for the package is necessarily technical.
The following paragraphs should answer the following questions: Why do I as a user need this package? What other features does the package have? What outstanding features and deficiencies are there compared to other packages (e.g., "if you need X, use Y instead")? Is this package related to other packages in some way that is not handled by the package manager (e.g., "this is the client to the foo server")?
Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check
it. ispell
has a special -g option for
debian/control
files:
ispell -d american -g debian/control
We recommend that you add the URL for the package's home page to the package
description in debian/control
. This information should be added
at the end of description, using the following format:
. Homepage: http://some-project.some-place.org/
Note the spaces prepending the line, which serves to break the lines correctly.
To see an example of how this displays, see http://packages.debian.org/unstable/text/docbook-dsssl.html
.
If there is no home page for the software, this should naturally be left out.
Note that we expect this field will eventually be replaced by a proper
debian/control
field understood by dpkg
and
packages.debian.org. If you don't want to bother migrating the
home page from the description to this field, you should probably wait until
that is available.
debian/changelog
The following practices supplement the Policy
on changelog files
.
The changelog entry for a package revision documents changes in that revision, and only them. Concentrate on describing significant and user-visible changes that were made since the last version.
Focus on what was changed — who, how and when are usually less important. Having said that, remember to politely attribute people who have provided notable help in making the package (e.g., those who have sent in patches).
There's no need to elaborate the trivial and obvious changes. You can also
aggregate several changes in one entry. On the other hand, don't be overly
terse if you have undertaken a major change. Be especially clear if there are
changes that affect the behaviour of the program. For further explanations,
use the README.Debian
file.
Use common English so that the majority of readers can comprehend it. Avoid abbreviations, "tech-speak" and jargon when explaining changes that close bugs, especially for bugs filed by users that did not strike you as particularly technically savvy. Be polite, don't swear.
It is sometimes desirable to prefix changelog entries with the names of the files that were changed. However, there's no need to explicitly list each and every last one of the changed files, especially if the change was small or repetitive. You may use wildcards.
When referring to bugs, don't assume anything. Say what the problem was, how it was fixed, and append the "closes: #nnnnn" string. See When bugs are closed by new uploads, Section 5.8.4 for more information.
The changelog entries should not document generic packaging issues ("Hey, if you're looking for foo.conf, it's in /etc/blah/."), since administrators and users are supposed to be at least remotely acquainted with how such things are generally arranged on Debian systems. Do, however, mention if you change the location of a configuration file.
The only bugs closed with a changelog entry should be those that are actually fixed in the same package revision. Closing unrelated bugs in the changelog is bad practice. See When bugs are closed by new uploads, Section 5.8.4.
The changelog entries should not be used for random discussion with bug reporters ("I don't see segfaults when starting foo with option bar; send in more info"), general statements on life, the universe and everything ("sorry this upload took me so long, but I caught the flu"), or pleas for help ("the bug list on this package is huge, please lend me a hand"). Such things usually won't be noticed by their target audience, but may annoy people who wish to read information about actual changes in the package. See Responding to bugs, Section 5.8.2 for more information on how to use the bug tracking system.
It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in the first changelog entry of the proper maintainer upload, for instance, in a changelog entry like this:
* Maintainer upload, closes: #42345, #44484, #42444.
This will close the NMU bugs tagged "fixed" when the package makes it into the archive. The bug for the fact that an NMU was done can be closed the same way. Of course, it's also perfectly acceptable to close NMU-fixed bugs by other means; see Responding to bugs, Section 5.8.2.
The following examples demonstrate some common errors or example of bad style in changelog entries.
* Fixed all outstanding bugs.
This doesn't tell readers anything too useful, obviously.
* Applied patch from Jane Random.
What was the patch about?
* Late night install target overhaul.
Overhaul which accomplished what? Is the mention of late night supposed to remind us that we shouldn't trust that code?
* Fix vsync FU w/ ancient CRTs.
Too many acronyms, and it's not overly clear what the, uh, fsckup (oops, a curse word!) was actually about, or how it was fixed.
* This is not a bug, closes: #nnnnnn.
First of all, there's absolutely no need to upload the package to convey this information; instead, use the bug tracking system. Secondly, there's no explanation as to why the report is not a bug.
* Has been fixed for ages, but I forgot to close; closes: #54321.
If for some reason you didn't mention the bug number in a previous changelog entry, there's no problem, just close the bug normally in the BTS. There's no need to touch the changelog file, presuming the description of the fix is already in (this applies to the fixes by the upstream authors/maintainers as well, you don't have to track bugs that they fixed ages ago in your changelog).
* Closes: #12345, #12346, #15432
Where's the description? If you can't think of a descriptive message, start by inserting the title of each different bug.
Maintainer scripts include the files debian/postinst
,
debian/preinst
, debian/prerm
and
debian/postrm
. These scripts take care of any package
installation or deinstallation setup which isn't handled merely by the creation
or removal of files and directories. The following instructions supplement the
Debian
Policy
.
Maintainer scripts must be idempotent. That means that you need to make sure nothing bad will happen if the script is called twice where it would usually be called once.
Standard input and output may be redirected (e.g. into pipes) for logging purposes, so don't rely on them being a tty.
All prompting or interactive configuration should be kept to a minimum. When
it is necessary, you should use the debconf
package for the
interface. Remember that prompting in any case can only be in the
configure stage of the postinst
script.
Keep the maintainer scripts as simple as possible. We suggest you use pure
POSIX shell scripts. Remember, if you do need any bash features, the
maintainer script must have a bash sh-bang line. POSIX shell or Bash are
preferred to Perl, since they enable debhelper
to easily add bits
to the scripts.
If you change your maintainer scripts, be sure to test package removal, double installation, and purging. Be sure that a purged package is completely gone, that is, it must remove any files created, directly or indirectly, in any maintainer script.
If you need to check for the existence of a command, you should use something like
if [ -x /usr/sbin/install-docs ]; then ...
If you don't wish to hard-code the path of the command in your maintainer script, the following POSIX-compliant shell function may help:
pathfind() { OLDIFS="$IFS" IFS=: for p in $PATH; do if [ -x "$p/$*" ]; then IFS="$OLDIFS" return 0 fi done IFS="$OLDIFS" return 1 }
You can use this function to search $PATH for a command name,
passed as an argument. It returns true (zero) if the command was found, and
false if not. This is really the most portable way, since command
-v, type
, and which
are not POSIX.
While which
is an acceptable alternative, since it is from the
required debianutils
package, it's not on the root partition.
That is, it's in /usr/bin
rather than /bin
, so one
can't use it in scripts which are run before the /usr
partition is
mounted. Most scripts won't have this problem, though.
debconf
Debconf
is a configuration management system which can be used by
all the various packaging scripts (postinst
mainly) to request
feedback from the user concerning how to configure the package. Direct user
interactions must now be avoided in favor of debconf
interaction.
This will enable non-interactive installations in the future.
Debconf is a great tool but it is often poorly used. Many common mistakes are
listed in the debconf-devel(7)
man page. It is something that you
must read if you decide to use debconf.
Like porters, translators have a difficult task. They work on many packages and must collaborate with many different maintainers. Moreover, most of the time, they are not native English speakers, so you may need to be particularly patient with them.
The goal of debconf
was to make packages configuration easier for
maintainers and for users. Originally, translation of debconf templates was
handled with debconf-mergetemplate
. However, that technique is
now deprecated; the best way to accomplish debconf
internationalization is by using the po-debconf
package. This
method is easier both for maintainer and translators; transition scripts are
provided.
Using po-debconf
, the translation is stored in po
files (drawing from gettext
translation techniques). Special
template files contain the original messages and mark which fields are
translatable. When you change the value of a translatable field, by calling
debconf-updatepo
, the translation is marked as needing attention
from the translators. Then, at build time, the dh_installdebconf
program takes care of all the needed magic to add the template along with the
up-to-date translations into the binary packages. Refer to the
po-debconf(7)
manual page for details.
Internationalizing documentation is crucial for users, but a lot of labor. There's no way to eliminate all that work, but you can make things easier for translators.
If you maintain documentation of any size, its easier for translators if they
have access to a source control system. That lets translators see the
differences between two versions of the documentation, so, for instance, they
can see what needs to be retranslated. It is recommended that the translated
documentation maintain a note about what source control revision the
translation is based on. An interesting system is provided by doc-check
in the boot-floppies
package, which shows an overview of the
translation status for any given language, using structured comments for the
current revision of the file to be translated and, for a translated file, the
revision of the original file the translation is based on. You might wish to
adapt and provide that in your CVS area.
If you maintain XML or SGML documentation, we suggest that you isolate any language-independent information and define those as entities in a separate file which is included by all the different translations. This makes it much easier, for instance, to keep URLs up-to-date across multiple files.
autoconf
/automake
Keeping autoconf
's config.sub
and
config.guess
files up-to-date is critical for porters, especially
on more volatile architectures. Some very good packaging practices for any
package using autoconf
and/or automake
have been
synthesized in /usr/share/doc/autotools-dev/README.Debian.gz
from
the autotools-dev
package. You're strongly encouraged to read
this file and to follow the given recommendations.
Libraries are always difficult to package for various reasons. The policy imposes many constraints to ease their maintenance and to make sure upgrades are as simple as possible when a new upstream version comes out. A breakage in a library can result in dozens of dependent packages breaking.
Good practices for library packaging have been grouped in the library
packaging guide
.
Be sure to follow the Policy on
documentation
.
If your package contains documentation built from XML or SGML, we recommend you not ship the XML or SGML source in the binary package(s). If users want the source of the documentation, they should retrieve the source package.
Policy specifies that documentation should be shipped in HTML format. We also recommend shipping documentation in PDF and plain text format if convenient and quality output is possible. However, it is generally not appropriate to ship plain text versions of documentation whose source format is HTML.
Major shipped manuals should register themselves with doc-base
on
installation. See the doc-base
package documentation for more
information.
Several specific types of packages have special sub-policies and corresponding packaging rules and practices:
Perl
policy
, some examples of packages following that policy are
libdbd-pg-perl
(binary perl module) or libmldbm-perl
(arch independent perl module).
/usr/share/doc/python/python-policy.txt.gz
in the
python
package.
emacs
policy
.
java
policy
.
/usr/share/doc/ocaml/ocaml_packaging_policy.gz
from the
ocaml
package. A good example is the camlzip
source
package.
sgml-base-doc
package.
common-lisp-controller
, about which see
/usr/share/doc/common-lisp-controller/README.packaging
.
It is not uncommon to have a large amount of architecture-independent data packaged with a program. For example, audio files, a collection of icons, wallpaper patterns, or other graphic files. If the size of this data is negligible compared to the size of the rest of the package, it's probably best to keep it all in a single package.
However, if the size of the data is considerable, consider splitting it out
into a separate, architecture-independent package ("_all.deb"). By
doing this, you avoid needless duplication of the same data into eleven or more
.debs, one per each architecture. While this adds some extra overhead into the
Packages
files, it saves a lot of disk space on Debian mirrors.
Separating out architecture-independent data also reduces processing time of
lintian
or linda
(see Package lint tools, Section A.2) when
run over the entire Debian archive.
Debian Developer's Reference
ver. 3.3.4, 29 February, 2004developers-reference@packages.debian.org