LDP
/
old-www
1
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity
old-www/LDP/www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html

1175 lines
92 KiB
HTML
Raw Permalink Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 6. Best Packaging Practices</title><meta name="generator" content="DocBook XSL Stylesheets V1.76.1" /><link rel="home" href="index.html" title="Debian Developer's Reference" /><link rel="up" href="index.html" title="Debian Developer's Reference" /><link rel="prev" href="pkgs.html" title="Chapter 5. Managing Packages" /><link rel="next" href="beyond-pkging.html" title="Chapter 7. Beyond Packaging" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">Chapter 6. Best Packaging Practices</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="pkgs.html">Prev</a> </td><th width="60%" align="center"> </th><td width="20%" align="right"> <a accesskey="n" href="beyond-pkging.html">Next</a></td></tr></table><hr /></div><div class="chapter" title="Chapter 6. Best Packaging Practices"><div class="titlepage"><div><div><h2 class="title"><a id="best-pkging-practices"></a>Chapter 6. Best Packaging Practices</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl><dt><span class="section"><a href="best-pkging-practices.html#bpp-debian-rules">6.1. Best practices for <code class="filename">debian/rules</code></a></span></dt><dd><dl><dt><span class="section"><a href="best-pkging-practices.html#helper-scripts">6.1.1. Helper scripts</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#multiple-patches">6.1.2. Separating your patches into multiple files</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#multiple-binary">6.1.3. Multiple binary packages</a></span></dt></dl></dd><dt><span class="section"><a href="best-pkging-practices.html#bpp-debian-control">6.2. Best practices for <code class="filename">debian/control</code></a></span></dt><dd><dl><dt><span class="section"><a href="best-pkging-practices.html#bpp-desc-basics">6.2.1. General guidelines for package descriptions</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-pkg-synopsis">6.2.2. The package synopsis, or short description</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-pkg-desc">6.2.3. The long description</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-upstream-info">6.2.4. Upstream home page</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-vcs">6.2.5. Version Control System location</a></span></dt></dl></dd><dt><span class="section"><a href="best-pkging-practices.html#bpp-debian-changelog">6.3. Best practices for <code class="filename">debian/changelog</code></a></span></dt><dd><dl><dt><span class="section"><a href="best-pkging-practices.html#bpp-changelog-do">6.3.1. Writing useful changelog entries</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-changelog-misconceptions">6.3.2. Common misconceptions about changelog entries</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-changelog-errors">6.3.3. Common errors in changelog entries</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-news-debian">6.3.4. Supplementing changelogs with <code class="filename">NEWS.Debian</code> files</a></span></dt></dl></dd><dt><span class="section"><a href="best-pkging-practices.html#bpp-debian-maint-scripts">6.4. Best practices for maintainer scripts</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-config-mgmt">6.5. Configuration management with <code class="systemitem">debconf</code></a></span></dt><dd><dl><dt><span class="section"><a href="best-pkging-practices.html#s6.5.1">6.5.1. Do not abuse debconf</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#s6.5.2">6.5.2. General recommendations for authors and translators</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#s6.5.3">6.5.3. Templates fields definition</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#s6.5.4">6.5.4. Templates fields specific style guide</a></span></dt></dl></dd><dt><span class="section"><a href="best-pkging-practices.html#bpp-i18n">6.6. Internationalization</a></span></dt><dd><dl><dt><span class="section"><a href="best-pkging-practices.html#bpp-i18n-debconf">6.6.1. Handling debconf translations</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-i18n-docs">6.6.2. Internationalized documentation</a></span></dt></dl></dd><dt><span class="section"><a href="best-pkging-practices.html#bpp-common-situations">6.7. Common packaging situations</a></span></dt><dd><dl><dt><span class="section"><a href="best-pkging-practices.html#bpp-autotools">6.7.1. Packages using <span class="command"><strong>autoconf</strong></span>/<span class="command"><strong>automake</strong></span></a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-libraries">6.7.2. Libraries</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-docs">6.7.3. Documentation</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-other">6.7.4. Specific types of packages</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-archindepdata">6.7.5. Architecture-independent data</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-locale">6.7.6. Needing a certain locale during build</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-transition">6.7.7. Make transition packages deborphan compliant</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-origtargz">6.7.8. Best practices for <code class="filename">.orig.tar.{gz,bz2,xz}</code> files</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-dbg">6.7.9. Best practices for debug packages</a></span></dt><dt><span class="section"><a href="best-pkging-practices.html#bpp-meta">6.7.10. Best practices for meta-packages</a></span></dt></dl></dd></dl></div><p>
Debian's quality is largely due to the <a class="ulink" href="http://www.debian.org/doc/debian-policy/" target="_top">Debian Policy</a>, 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.
</p><p>
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.
</p><div class="section" title="6.1. Best practices for debian/rules"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-debian-rules"></a>6.1. Best practices for <code class="filename">debian/rules</code></h2></div></div></div><p>
The following recommendations apply to the <code class="filename">debian/rules</code>
file. Since <code class="filename">debian/rules</code> 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.
</p><div class="section" title="6.1.1. Helper scripts"><div class="titlepage"><div><div><h3 class="title"><a id="helper-scripts"></a>6.1.1. Helper scripts</h3></div></div></div><p>
The rationale for using helper scripts in <code class="filename">debian/rules</code> is
that they let 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 <code class="filename">/usr/share/menu</code> (or <code class="filename">/usr/lib/menu</code>
for executable binary menufiles, if this is needed), 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.
</p><p>
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.
</p><p>
<a class="xref" href="tools.html" title="Appendix A. Overview of Debian Maintainer Tools">Appendix A, <em>Overview of Debian Maintainer Tools</em></a> contains a couple of different helpers. The most
common and best (in our opinion) helper system is <code class="systemitem">debhelper</code>. Previous helper systems, such as
<code class="systemitem">debmake</code>, 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. <code class="systemitem">debhelper</code>,
however, is a number of separate little <span class="command"><strong>dh_*</strong></span> programs. For
instance, <span class="command"><strong>dh_installman</strong></span> installs and compresses man pages,
<span class="command"><strong>dh_installmenu</strong></span> 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
<code class="filename">debian/rules</code>.
</p><p>
You can get started with <code class="systemitem">debhelper</code> by
reading <span class="citerefentry"><span class="refentrytitle">debhelper</span>(1)</span>, and looking at the examples that come
with the package. <span class="command"><strong>dh_make</strong></span>, from the <code class="systemitem">dh-make</code> package (see <a class="xref" href="tools.html#dh-make" title="A.3.2. dh-make">Section A.3.2, “<code class="systemitem">dh-make</code>”</a>),
can be used to convert a vanilla source package to a <code class="systemitem">debhelper</code>ized package. This shortcut, though,
should not convince you that you do not need to bother understanding the
individual <span class="command"><strong>dh_*</strong></span> 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.
</p><p>
Some people feel that vanilla <code class="filename">debian/rules</code> 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 <code class="filename">debian/rules</code> files are available at <a class="ulink" href="http://arch.debian.org/arch/private/srivasta/" target="_top">http://arch.debian.org/arch/private/srivasta/</a>.
</p></div><div class="section" title="6.1.2. Separating your patches into multiple files"><div class="titlepage"><div><div><h3 class="title"><a id="multiple-patches"></a>6.1.2. Separating your patches into multiple files</h3></div></div></div><p>
Big, complex packages may have many bugs that you need to deal with. If you
correct a number of bugs directly in the source, and 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 <code class="filename">.diff.gz</code>) and work out which patch sets
to back out as a unit as bugs are fixed upstream.
</p><p>
Fortunately, with the source format “3.0 (quilt)” it is now possible to
keep patches separate without having to modify <code class="filename">debian/rules</code>
to setup a patch system. Patches are stored in <code class="filename">debian/patches/</code>
and when the source package is unpacked patches listed in
<code class="filename">debian/patches/series</code> are automatically applied.
As the name implies, patches can be managed with <span class="command"><strong>quilt</strong></span>.
</p><p>
When using the older source “1.0”, it's also possible to separate patches
but a dedicated patch system must be used: the patch files are shipped
within the Debian patch file (<code class="filename">.diff.gz</code>), usually
within the <code class="filename">debian/</code> directory. The only difference is
that they aren't applied immediately by <span class="command"><strong>dpkg-source</strong></span>,
but by the <code class="literal">build</code> rule of
<code class="filename">debian/rules</code>, through a dependency on the
<code class="literal">patch</code> rule. Conversely, they are reverted in the
<code class="literal">clean</code> rule, through a dependency on the
<code class="literal">unpatch</code> rule.
</p><p>
<span class="command"><strong>quilt</strong></span> is the recommended tool for this.
It does all of the above, and also allows to manage patch series.
See the
<code class="systemitem">quilt</code> package for more information.
</p><p>
There are other tools to manage patches, like <span class="command"><strong>dpatch</strong></span>,
and the patch system integrated with
<code class="systemitem">cdbs</code>.
</p></div><div class="section" title="6.1.3. Multiple binary packages"><div class="titlepage"><div><div><h3 class="title"><a id="multiple-binary"></a>6.1.3. Multiple binary packages</h3></div></div></div><p>
A single source package will often build several binary packages, either to
provide several flavors of the same software (e.g., the <code class="systemitem">vim</code> source package) or to make several small
packages instead of a big one (e.g., so the user can install only the subset
needed, and thus save some disk space).
</p><p>
The second case can be easily managed in <code class="filename">debian/rules</code>.
You just need to move the appropriate files from the build directory into the
package's temporary trees. You can do this using <span class="command"><strong>install</strong></span> or
<span class="command"><strong>dh_install</strong></span> from <code class="systemitem">debhelper</code>. Be sure to check the different
permutations of the various packages, ensuring that you have the inter-package
dependencies set right in <code class="filename">debian/control</code>.
</p><p>
The first case is a bit more difficult since it involves multiple recompiles of
the same software but with different configuration options. The <code class="systemitem">vim</code> source package is an example of how to manage
this using an hand-crafted <code class="filename">debian/rules</code> file.
</p></div></div><div class="section" title="6.2. Best practices for debian/control"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-debian-control"></a>6.2. Best practices for <code class="filename">debian/control</code></h2></div></div></div><p>
The following practices are relevant to the <code class="filename">debian/control</code>
file. They supplement the <a class="ulink" href="http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions" target="_top">Policy
on package descriptions</a>.
</p><p>
The description of the package, as defined by the corresponding field in the
<code class="filename">control</code> file, contains both the package synopsis and the
long description for the package. <a class="xref" href="best-pkging-practices.html#bpp-desc-basics" title="6.2.1. General guidelines for package descriptions">Section 6.2.1, “General guidelines for package descriptions”</a> describes
common guidelines for both parts of the package description. Following that,
<a class="xref" href="best-pkging-practices.html#bpp-pkg-synopsis" title="6.2.2. The package synopsis, or short description">Section 6.2.2, “The package synopsis, or short description”</a> provides guidelines specific to the
synopsis, and <a class="xref" href="best-pkging-practices.html#bpp-pkg-desc" title="6.2.3. The long description">Section 6.2.3, “The long description”</a> contains guidelines specific to
the description.
</p><div class="section" title="6.2.1. General guidelines for package descriptions"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-desc-basics"></a>6.2.1. General guidelines for package descriptions</h3></div></div></div><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
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.
</p><p>
If you are having problems writing your description, you may wish to send it
along to <code class="email">&lt;<a class="email" href="mailto:debian-l10n-english@lists.debian.org">debian-l10n-english@lists.debian.org</a>&gt;</code> and request feedback.
</p></div><div class="section" title="6.2.2. The package synopsis, or short description"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-pkg-synopsis"></a>6.2.2. The package synopsis, or short description</h3></div></div></div><p>
Policy says the synopsis line (the short description) must be concise, not
repeating the package name, but also informative.
</p><p>
The synopsis functions as a phrase describing the package, not a complete
sentence, so sentential punctuation is inappropriate: it does not need extra
capital letters or a final period (full stop). It should also omit any initial
indefinite or definite article — "a", "an", or "the". Thus for instance:
</p><pre class="screen">
Package: libeg0
Description: exemplification support library
</pre><p>
Technically this is a noun phrase minus articles, as opposed to a verb phrase.
A good heuristic is that it should be possible to substitute the package
<em class="replaceable"><code>name</code></em> and <em class="replaceable"><code>synopsis</code></em> into this formula:
</p><p>
The package <em class="replaceable"><code>name</code></em> provides {a,an,the,some}
<em class="replaceable"><code>synopsis</code></em>.
</p><p>
Sets of related packages may use an alternative scheme that divides the
synopsis into two parts, the first a description of the whole suite and the
second a summary of the package's role within it:
</p><pre class="screen">
Package: eg-tools
Description: simple exemplification system (utilities)
Package: eg-doc
Description: simple exemplification system - documentation
</pre><p>
These synopses follow a modified formula. Where a package
"<em class="replaceable"><code>name</code></em>" has a synopsis
"<em class="replaceable"><code>suite</code></em> (<em class="replaceable"><code>role</code></em>)" or
"<em class="replaceable"><code>suite</code></em> - <em class="replaceable"><code>role</code></em>", the
elements should be phrased so that they fit into the formula:
</p><p>
The package <em class="replaceable"><code>name</code></em> provides {a,an,the}
<em class="replaceable"><code>role</code></em> for the <em class="replaceable"><code>suite</code></em>.
</p></div><div class="section" title="6.2.3. The long description"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-pkg-desc"></a>6.2.3. The long description</h3></div></div></div><p>
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.
</p><p>
The long description should consist of full and complete sentences.
</p><p>
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.
</p><p>
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 for the foo server)?
</p><p>
Be careful to avoid spelling and grammar mistakes. Ensure that you spell-check
it. Both <span class="command"><strong>ispell</strong></span> and <span class="command"><strong>aspell</strong></span> have special
modes for checking <code class="filename">debian/control</code> files:
</p><pre class="screen">
ispell -d american -g debian/control
</pre><pre class="screen">
aspell -d en -D -c debian/control
</pre><p>
Users usually expect these questions to be answered in the package description:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
What does the package do? If it is an add-on to another package, then the
short description of the package we are an add-on to should be put in here.
</p></li><li class="listitem"><p>
Why should I want this package? This is related to the above, but not the same
(this is a mail user agent; this is cool, fast, interfaces with PGP and LDAP
and IMAP, has features X, Y, and Z).
</p></li><li class="listitem"><p>
If this package should not be installed directly, but is pulled in by another
package, this should be mentioned.
</p></li><li class="listitem"><p>
If the package is <code class="literal">experimental</code>, or there are other reasons
it should not be used, if there are other packages that should be used instead,
it should be here as well.
</p></li><li class="listitem"><p>
How is this package different from the competition? Is it a better
implementation? more features? different features? Why should I choose this
package.
</p></li></ul></div></div><div class="section" title="6.2.4. Upstream home page"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-upstream-info"></a>6.2.4. Upstream home page</h3></div></div></div><p>
We recommend that you add the URL for the package's home page in the
<code class="literal">Homepage</code> field of the <code class="literal">Source</code> section
in <code class="filename">debian/control</code>. Adding this information in the
package description itself is considered deprecated.
</p></div><div class="section" title="6.2.5. Version Control System location"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-vcs"></a>6.2.5. Version Control System location</h3></div></div></div><p>
There are additional fields for the location of the Version Control System in
<code class="filename">debian/control</code>.
</p><div class="section" title="6.2.5.1. Vcs-Browser"><div class="titlepage"><div><div><h4 class="title"><a id="s6.2.5.1"></a>6.2.5.1. Vcs-Browser</h4></div></div></div><p>
Value of this field should be a <code class="literal">http://</code> URL pointing to a
web-browsable copy of the Version Control System repository used to maintain
the given package, if available.
</p><p>
The information is meant to be useful for the final user, willing to browse the
latest work done on the package (e.g. when looking for the patch fixing a bug
tagged as <code class="literal">pending</code> in the bug tracking system).
</p></div><div class="section" title="6.2.5.2. Vcs-*"><div class="titlepage"><div><div><h4 class="title"><a id="s6.2.5.2"></a>6.2.5.2. Vcs-*</h4></div></div></div><p>
Value of this field should be a string identifying unequivocally the location
of the Version Control System repository used to maintain the given package, if
available. <code class="literal">*</code> identify the Version Control System; currently
the following systems are supported by the package tracking system:
<code class="literal">arch</code>, <code class="literal">bzr</code> (Bazaar),
<code class="literal">cvs</code>, <code class="literal">darcs</code>, <code class="literal">git</code>,
<code class="literal">hg</code> (Mercurial), <code class="literal">mtn</code> (Monotone),
<code class="literal">svn</code> (Subversion). It is allowed to specify different VCS
fields for the same package: they will all be shown in the PTS web interface.
</p><p>
The information is meant to be useful for a user knowledgeable in the given
Version Control System and willing to build the current version of a package
from the VCS sources. Other uses of this information might include automatic
building of the latest VCS version of the given package. To this end the
location pointed to by the field should better be version agnostic and point to
the main branch (for VCSs supporting such a concept). Also, the location
pointed to should be accessible to the final user; fulfilling this requirement
might imply pointing to an anonymous access of the repository instead of
pointing to an SSH-accessible version of the same.
</p><p>
In the following example, an instance of the field for a Subversion repository
of the <code class="systemitem">vim</code> package is shown. Note how
the URL is in the <code class="literal">svn://</code> scheme (instead of
<code class="literal">svn+ssh://</code>) and how it points to the
<code class="filename">trunk/</code> branch. The use of the
<code class="literal">Vcs-Browser</code> and <code class="literal">Homepage</code> fields
described above is also shown.
</p><pre class="screen">
Source: vim
Section: editors
Priority: optional
&lt;snip&gt;
Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
Homepage: http://www.vim.org
</pre></div></div></div><div class="section" title="6.3. Best practices for debian/changelog"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-debian-changelog"></a>6.3. Best practices for <code class="filename">debian/changelog</code></h2></div></div></div><p>
The following practices supplement the <a class="ulink" href="http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs" target="_top">Policy
on changelog files</a>.
</p><div class="section" title="6.3.1. Writing useful changelog entries"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-changelog-do"></a>6.3.1. Writing useful changelog entries</h3></div></div></div><p>
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.
</p><p>
Focus on <span class="emphasis"><em>what</em></span> 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).
</p><p>
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 <code class="filename">README.Debian</code> file.
</p><p>
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.
</p><p>
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.
</p><p>
When referring to bugs, don't assume anything. Say what the problem was, how
it was fixed, and append the closes: #nnnnn string. See <a class="xref" href="pkgs.html#upload-bugfix" title="5.8.4. When bugs are closed by new uploads">Section 5.8.4, “When bugs are closed by new uploads”</a> for more information.
</p></div><div class="section" title="6.3.2. Common misconceptions about changelog entries"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-changelog-misconceptions"></a>6.3.2. Common misconceptions about changelog entries</h3></div></div></div><p>
The changelog entries should <span class="strong"><strong>not</strong></span> 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.
</p><p>
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 <a class="xref" href="pkgs.html#upload-bugfix" title="5.8.4. When bugs are closed by new uploads">Section 5.8.4, “When bugs are closed by new uploads”</a>.
</p><p>
The changelog entries should <span class="strong"><strong>not</strong></span> 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
<a class="xref" href="pkgs.html#bug-answering" title="5.8.2. Responding to bugs">Section 5.8.2, “Responding to bugs”</a> for more information on how to use the bug
tracking system.
</p><p>
It is an old tradition to acknowledge bugs fixed in non-maintainer uploads in
the first changelog entry of the proper maintainer upload. As we have version
tracking now, it is enough to keep the NMUed changelog entries and just mention
this fact in your own changelog entry.
</p></div><div class="section" title="6.3.3. Common errors in changelog entries"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-changelog-errors"></a>6.3.3. Common errors in changelog entries</h3></div></div></div><p>
The following examples demonstrate some common errors or examples of bad style
in changelog entries.
</p><pre class="screen">
* Fixed all outstanding bugs.
</pre><p>
This doesn't tell readers anything too useful, obviously.
</p><pre class="screen">
* Applied patch from Jane Random.
</pre><p>
What was the patch about?
</p><pre class="screen">
* Late night install target overhaul.
</pre><p>
Overhaul which accomplished what? Is the mention of late night supposed to
remind us that we shouldn't trust that code?
</p><pre class="screen">
* Fix vsync FU w/ ancient CRTs.
</pre><p>
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.
</p><pre class="screen">
* This is not a bug, closes: #nnnnnn.
</pre><p>
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.
</p><pre class="screen">
* Has been fixed for ages, but I forgot to close; closes: #54321.
</pre><p>
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).
</p><pre class="screen">
* Closes: #12345, #12346, #15432
</pre><p>
Where's the description? If you can't think of a descriptive message, start by
inserting the title of each different bug.
</p></div><div class="section" title="6.3.4. Supplementing changelogs with NEWS.Debian files"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-news-debian"></a>6.3.4. Supplementing changelogs with <code class="filename">NEWS.Debian</code> files</h3></div></div></div><p>
Important news about changes in a package can also be put in
<code class="filename">NEWS.Debian</code> files.
The news will be displayed by tools like <code class="systemitem">apt-listchanges</code>, before all the rest
of the changelogs. This is the preferred means to let the user know about
significant changes in a package. It is better than using <code class="systemitem">debconf</code> notes since
it is less annoying and the user can go back and refer to the
<code class="filename">NEWS.Debian</code> file after the install. And it's better than listing
major changes in <code class="filename">README.Debian</code>, since the user can easily
miss such notes.
</p><p>
The file format is the same as a debian changelog file, but leave off the
asterisks and describe each news item with a full paragraph when necessary
rather than the more concise summaries that would go in a changelog. It's a
good idea to run your file through <code class="literal">dpkg-parsechangelog</code> to
check its formatting as it will not be automatically checked during build as
the changelog is. Here is an example of a real
<code class="filename">NEWS.Debian</code> file:
</p><pre class="screen">
cron (3.0pl1-74) unstable; urgency=low
The checksecurity script is no longer included with the cron package:
it now has its own package, checksecurity. If you liked the
functionality provided with that script, please install the new
package.
-- Steve Greenland &lt;stevegr@debian.org&gt; Sat, 6 Sep 2003 17:15:03 -0500
</pre><p>
The <code class="filename">NEWS.Debian</code> file is installed as
<code class="filename">/usr/share/doc/<em class="replaceable"><code>package</code></em>/NEWS.Debian.gz</code>.
It is compressed, and always has that name even in Debian native packages.
If you use <code class="literal">debhelper</code>, <code class="literal">dh_installchangelogs</code>
will install <code class="filename">debian/NEWS</code> files for you.
</p><p>
Unlike changelog files, you need not update <code class="filename">NEWS.Debian</code>
files with every release. Only update them if you have something particularly
newsworthy that user should know about. If you have no news at all, there's no
need to ship a <code class="filename">NEWS.Debian</code> file in your package. No news
is good news!
</p></div></div><div class="section" title="6.4. Best practices for maintainer scripts"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-debian-maint-scripts"></a>6.4. Best practices for maintainer scripts</h2></div></div></div><p>
Maintainer scripts include the files <code class="filename">debian/postinst</code>,
<code class="filename">debian/preinst</code>, <code class="filename">debian/prerm</code> and
<code class="filename">debian/postrm</code>. 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
<a class="ulink" href="http://www.debian.org/doc/debian-policy/" target="_top">Debian Policy</a>.
</p><p>
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.
</p><p>
Standard input and output may be redirected (e.g. into pipes) for logging
purposes, so don't rely on them being a tty.
</p><p>
All prompting or interactive configuration should be kept to a minimum. When
it is necessary, you should use the <code class="systemitem">debconf</code> package for the interface. Remember that
prompting in any case can only be in the <code class="literal">configure</code> stage of
the <code class="filename">postinst</code> script.
</p><p>
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 shebang line. POSIX shell or Bash are
preferred to Perl, since they enable <code class="systemitem">debhelper</code> to easily add bits to the scripts.
</p><p>
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.
</p><p>
If you need to check for the existence of a command, you should use something
like
</p><pre class="programlisting">if [ -x /usr/sbin/install-docs ]; then ...</pre><p>
If you don't wish to hard-code the path of a command in your maintainer script,
the following POSIX-compliant shell function may help:
</p><pre class="programlisting">pathfind() {
OLDIFS="$IFS"
IFS=:
for p in $PATH; do
if [ -x "$p/$*" ]; then
IFS="$OLDIFS"
return 0
fi
done
IFS="$OLDIFS"
return 1
}</pre><p>
You can use this function to search <code class="varname">$PATH</code> 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 <code class="literal">command
-v</code>, <span class="command"><strong>type</strong></span>, and <span class="command"><strong>which</strong></span> are not
POSIX.
</p><p>
While <span class="command"><strong>which</strong></span> is an acceptable alternative, since it is from
the required <code class="systemitem">debianutils</code> package, it's
not on the root partition. That is, it's in <code class="filename">/usr/bin</code>
rather than <code class="filename">/bin</code>, so one can't use it in scripts which are
run before the <code class="filename">/usr</code> partition is mounted. Most scripts
won't have this problem, though.
</p></div><div class="section" title="6.5. Configuration management with debconf"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-config-mgmt"></a>6.5. Configuration management with <code class="systemitem">debconf</code></h2></div></div></div><p>
<code class="systemitem">Debconf</code> is a configuration management
system which can be used by all the various packaging scripts
(<code class="filename">postinst</code> mainly) to request feedback from the user
concerning how to configure the package. Direct user interactions must now be
avoided in favor of <code class="systemitem">debconf</code>
interaction. This will enable non-interactive installations in the future.
</p><p>
Debconf is a great tool but it is often poorly used. Many common mistakes are
listed in the <span class="citerefentry"><span class="refentrytitle">debconf-devel</span>(7)</span> man page. It is something that you
must read if you decide to use debconf. Also, we document some best practices
here.
</p><p>
These guidelines include some writing style and typography recommendations,
general considerations about debconf usage as well as more specific
recommendations for some parts of the distribution (the installation system for
instance).
</p><div class="section" title="6.5.1. Do not abuse debconf"><div class="titlepage"><div><div><h3 class="title"><a id="s6.5.1"></a>6.5.1. Do not abuse debconf</h3></div></div></div><p>
Since debconf appeared in Debian, it has been widely abused and several
criticisms received by the Debian distribution come from debconf abuse with the
need of answering a wide bunch of questions before getting any little thing
installed.
</p><p>
Keep usage notes to what they belong: the <code class="filename">NEWS.Debian</code>, or <code class="filename">README.Debian</code> file.
Only use notes for important notes which may directly affect the package
usability. Remember that notes will always block the install until confirmed
or bother the user by email.
</p><p>
Carefully choose the questions priorities in maintainer scripts. See
<span class="citerefentry"><span class="refentrytitle">debconf-devel</span>(7)</span> for details about priorities. Most
questions should use medium and low priorities.
</p></div><div class="section" title="6.5.2. General recommendations for authors and translators"><div class="titlepage"><div><div><h3 class="title"><a id="s6.5.2"></a>6.5.2. General recommendations for authors and translators</h3></div></div></div><div class="section" title="6.5.2.1. Write correct English"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.2.1"></a>6.5.2.1. Write correct English</h4></div></div></div><p>
Most Debian package maintainers are not native English speakers. So, writing
properly phrased templates may not be easy for them.
</p><p>
Please use (and abuse) <code class="email">&lt;<a class="email" href="mailto:debian-l10n-english@lists.debian.org">debian-l10n-english@lists.debian.org</a>&gt;</code> mailing
list. Have your templates proofread.
</p><p>
Badly written templates give a poor image of your package, of your work... or
even of Debian itself.
</p><p>
Avoid technical jargon as much as possible. If some terms sound common to you,
they may be impossible to understand for others. If you cannot avoid them, try
to explain them (use the extended description). When doing so, try to balance
between verbosity and simplicity.
</p></div><div class="section" title="6.5.2.2. Be kind to translators"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.2.2"></a>6.5.2.2. Be kind to translators</h4></div></div></div><p>
Debconf templates may be translated. Debconf, along with its sister package
<span class="command"><strong>po-debconf</strong></span> offers a simple framework for getting templates
translated by translation teams or even individuals.
</p><p>
Please use gettext-based templates. Install <code class="systemitem">po-debconf</code> on your development system and read its
documentation (<span class="command"><strong>man po-debconf</strong></span> is a good start).
</p><p>
Avoid changing templates too often. Changing templates text induces more work
to translators which will get their translation fuzzied. A fuzzy translation is
a string for which the original changed since it was translated, therefore
requiring some update by a translator to be usable. When changes are small
enough, the original translation is kept in PO files but marked as
<code class="literal">fuzzy</code>.
</p><p>
If you plan to do changes
to your original templates, please use the notification system provided with
the <code class="systemitem">po-debconf</code> package, namely the
<span class="command"><strong>podebconf-report-po</strong></span>, to contact translators. Most active
translators are very responsive and getting their work included along with your
modified templates will save you additional uploads. If you use gettext-based
templates, the translator's name and e-mail addresses are mentioned in the PO
files headers and will be used by
<span class="command"><strong>podebconf-report-po</strong></span>.
</p><p>
A recommended use of that utility is:
</p><pre class="programlisting">cd debian/po &amp;&amp; podebconf-report-po --call --languageteam --withtranslators --deadline="+10 days"</pre><p>
This command will first synchronize the PO and POT files in <code class="filename">debian/po</code> with
the templates files listed in <code class="filename">debian/po/POTFILES.in</code>.
Then, it will send a call for new translations, in the <code class="email">&lt;<a class="email" href="mailto:debian-i18n@lists.debian.org">debian-i18n@lists.debian.org</a>&gt;</code> mailing
list. Finally, it will also send a call for translation updates to the language team
(mentioned in the <code class="literal">Language-Team</code> field of each PO file)
as well as the last translator (mentioned in
<code class="literal">Last-translator</code>).
</p><p>
Giving a deadline to translators is always appreciated, so that they can
organize their work. Please remember that some translation teams have a
formalized translate/review process and a delay lower than 10 days is
considered as unreasonable. A shorter delay puts too much pressure on translation
teams and should be kept for very minor changes.
</p><p>
If in doubt, you may also contact the translation team for a given language
(debian-l10n-xxxxx@lists.debian.org), or the
<code class="email">&lt;<a class="email" href="mailto:debian-i18n@lists.debian.org">debian-i18n@lists.debian.org</a>&gt;</code> mailing list.
</p></div><div class="section" title="6.5.2.3. Unfuzzy complete translations when correcting typos and spelling"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.2.3"></a>6.5.2.3. Unfuzzy complete translations when correcting typos and spelling</h4></div></div></div><p>
When the text of a debconf template is corrected and you are <span class="strong"><strong>sure</strong></span> that the change does <span class="strong"><strong>not</strong></span> affect translations, please be kind to translators
and <span class="emphasis"><em>unfuzzy</em></span> their translations.
</p><p>
If you don't do so, the whole template will not be translated as long as a
translator will send you an update.
</p><p>
To <span class="emphasis"><em>unfuzzy</em></span> translations, you can use
<span class="command"><strong>msguntypot</strong></span> (part of the <code class="systemitem">po4a</code> package).
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
Regenerate the POT and PO files.
</p><pre class="programlisting">debconf-updatepo</pre></li><li class="listitem"><p>
Make a copy of the POT file.
</p><pre class="programlisting">cp templates.pot templates.pot.orig</pre></li><li class="listitem"><p>
Make a copy of all the PO files.
</p><pre class="programlisting">mkdir po_fridge; cp *.po po_fridge</pre></li><li class="listitem"><p>
Change the debconf template files to fix the typos.
</p></li><li class="listitem"><p>
Regenerate the POT and PO files (again).
</p><pre class="programlisting">debconf-updatepo</pre><p>
At this point, the typo fix fuzzied all the translations, and this
unfortunate change is the only one between the PO files of your main
directory and the one from the fridge. Here is how to solve this.
</p></li><li class="listitem"><p>
Discard fuzzy translation, restore the ones from the fridge.
</p><pre class="programlisting">cp po_fridge/*.po .</pre></li><li class="listitem"><p>
Manually merge the PO files with the new POT file, but taking the useless fuzzy into account.
</p><pre class="programlisting">msguntypot -o templates.pot.orig -n templates.pot *.po</pre></li><li class="listitem"><p>
Clean up.
</p><pre class="programlisting">rm -rf templates.pot.orig po_fridge</pre></li></ol></div></div><div class="section" title="6.5.2.4. Do not make assumptions about interfaces"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.2.4"></a>6.5.2.4. Do not make assumptions about interfaces</h4></div></div></div><p>
Templates text should not make reference to widgets belonging to some debconf
interfaces. Sentences like <span class="emphasis"><em>If you answer Yes...</em></span> have no meaning for users of
graphical interfaces which use checkboxes for boolean questions.
</p><p>
String templates should also avoid mentioning the default values in their
description. First, because this is redundant with the values seen by the
users. Also, because these default values may be different from the maintainer
choices (for instance, when the debconf database was preseeded).
</p><p>
More generally speaking, try to avoid referring to user actions. Just give
facts.
</p></div><div class="section" title="6.5.2.5. Do not use first person"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.2.5"></a>6.5.2.5. Do not use first person</h4></div></div></div><p>
You should avoid the use of first person (<span class="emphasis"><em>I will do this...</em></span> or <span class="emphasis"><em>We
recommend...</em></span>). The computer is not a person and the Debconf templates do not
speak for the Debian developers. You should use neutral construction. Those
of you who already wrote scientific publications, just write your templates
like you would write a scientific paper. However, try using active voice if
still possible, like <span class="emphasis"><em>Enable this if ...</em></span> instead of <span class="emphasis"><em>This can be enabled if...</em></span>.
</p></div><div class="section" title="6.5.2.6. Be gender neutral"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.2.6"></a>6.5.2.6. Be gender neutral</h4></div></div></div><p>
The world is made of men and women. Please use gender-neutral constructions in
your writing.
</p></div></div><div class="section" title="6.5.3. Templates fields definition"><div class="titlepage"><div><div><h3 class="title"><a id="s6.5.3"></a>6.5.3. Templates fields definition</h3></div></div></div><p>
This part gives some information which is mostly taken from the <span class="citerefentry"><span class="refentrytitle">debconf-devel</span>(7)</span> manual page.
</p><div class="section" title="6.5.3.1. Type"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.3.1"></a>6.5.3.1. Type</h4></div></div></div><div class="section" title="6.5.3.1.1. string"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.1"></a>6.5.3.1.1. string</h5></div></div></div><p>
Results in a free-form input field that the user can type any string into.
</p></div><div class="section" title="6.5.3.1.2. password"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.2"></a>6.5.3.1.2. password</h5></div></div></div><p>
Prompts the user for a password. Use this with caution; be aware that the
password the user enters will be written to debconf's database. You should
probably clean that value out of the database as soon as is possible.
</p></div><div class="section" title="6.5.3.1.3. boolean"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.3"></a>6.5.3.1.3. boolean</h5></div></div></div><p>
A true/false choice. Remember: true/false, <span class="strong"><strong>not
yes/no</strong></span>...
</p></div><div class="section" title="6.5.3.1.4. select"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.4"></a>6.5.3.1.4. select</h5></div></div></div><p>
A choice between one of a number of values. The choices must be specified in a
field named 'Choices'. Separate the possible values with commas and spaces,
like this: <code class="literal">Choices: yes, no, maybe</code>.
</p><p>
If choices are translatable strings, the 'Choices' field may be marked as
translatable by using <code class="literal">__Choices</code>. The double underscore will split out
each choice in a separate string.
</p><p>
The <span class="command"><strong>po-debconf</strong></span> system also offers interesting possibilities
to only mark <span class="strong"><strong>some</strong></span> choices as translatable.
Example:
</p><pre class="programlisting">
Template: foo/bar
Type: Select
#flag:translate:3
__Choices: PAL, SECAM, Other
_Description: TV standard:
Please choose the TV standard used in your country.
</pre><p>
In that example, only the 'Other' string is translatable while others
are acronyms that should not be translated. The above allows only
'Other' to be included in PO and POT files.
</p><p>
The debconf templates flag system offers many such possibilities. The
<span class="citerefentry"><span class="refentrytitle">po-debconf</span>(7)</span> manual page lists all these possibilities.
</p></div><div class="section" title="6.5.3.1.5. multiselect"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.5"></a>6.5.3.1.5. multiselect</h5></div></div></div><p>
Like the select data type, except the user can choose any number of items from
the choices list (or chose none of them).
</p></div><div class="section" title="6.5.3.1.6. note"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.6"></a>6.5.3.1.6. note</h5></div></div></div><p>
Rather than being a question per se, this datatype indicates a note that can be
displayed to the user. It should be used only for important notes that the
user really should see, since debconf will go to great pains to make sure the
user sees it; halting the install for them to press a key, and even mailing the
note to them in some cases.
</p></div><div class="section" title="6.5.3.1.7. text"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.7"></a>6.5.3.1.7. text</h5></div></div></div><p>
This type is now considered obsolete: don't use it.
</p></div><div class="section" title="6.5.3.1.8. error"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.3.1.8"></a>6.5.3.1.8. error</h5></div></div></div><p>
This type is designed to handle error messages. It is mostly similar to the
note type. Frontends may present it differently (for instance, the dialog
frontend of cdebconf draws a red screen instead of the usual blue one).
</p><p>
It is recommended to use this type for any message that needs user attention
for a correction of any kind.
</p></div></div><div class="section" title="6.5.3.2. Description: short and extended description"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.3.2"></a>6.5.3.2. Description: short and extended description</h4></div></div></div><p>
Template descriptions have two parts: short and extended. The short
description is in the Description: line of the template.
</p><p>
The short description should be kept short (50 characters or so) so that it may
be accommodated by most debconf interfaces. Keeping it short also helps
translators, as usually translations tend to end up being longer than the
original.
</p><p>
The short description should be able to stand on its own. Some interfaces do
not show the long description by default, or only if the user explicitely asks
for it or even do not show it at all. Avoid things like What do you want to
do?
</p><p>
The short description does not necessarily have to be a full sentence. This is
part of the keep it short and efficient recommendation.
</p><p>
The extended description should not repeat the short description word for word.
If you can't think up a long description, then first, think some more. Post to
debian-devel. Ask for help. Take a writing class! That extended description
is important. If after all that you still can't come up with anything, leave
it blank.
</p><p>
The extended description should use complete sentences. Paragraphs should be
kept short for improved readability. Do not mix two ideas in the same
paragraph but rather use another paragraph.
</p><p>
Don't be too verbose. User tend to ignore too long screens. 20 lines are by
experience a border you shouldn't cross, because that means that in the
classical dialog interface, people will need to scroll, and lot of people just
don't do that.
</p><p>
The extended description should <span class="strong"><strong>never</strong></span>
include a question.
</p><p>
For specific rules depending on templates type (string, boolean, etc.), please
read below.
</p></div><div class="section" title="6.5.3.3. Choices"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.3.3"></a>6.5.3.3. Choices</h4></div></div></div><p>
This field should be used for select and multiselect types. It contains the
possible choices which will be presented to users. These choices should be
separated by commas.
</p></div><div class="section" title="6.5.3.4. Default"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.3.4"></a>6.5.3.4. Default</h4></div></div></div><p>
This field is optional. It contains the default answer for string, select and
multiselect templates. For multiselect templates, it may contain a
comma-separated list of choices.
</p></div></div><div class="section" title="6.5.4. Templates fields specific style guide"><div class="titlepage"><div><div><h3 class="title"><a id="s6.5.4"></a>6.5.4. Templates fields specific style guide</h3></div></div></div><div class="section" title="6.5.4.1. Type field"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.4.1"></a>6.5.4.1. Type field</h4></div></div></div><p>
No specific indication except: use the appropriate type by referring to the
previous section.
</p></div><div class="section" title="6.5.4.2. Description field"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.4.2"></a>6.5.4.2. Description field</h4></div></div></div><p>
Below are specific instructions for properly writing the Description (short and
extended) depending on the template type.
</p><div class="section" title="6.5.4.2.1. String/password templates"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.4.2.1"></a>6.5.4.2.1. String/password templates</h5></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
The short description is a prompt and <span class="strong"><strong>not</strong></span> a
title. Avoid question style prompts (IP Address?) in favour of opened prompts
(IP address:). The use of colons is recommended.
</p></li><li class="listitem"><p>
The extended description is a complement to the short description. In the
extended part, explain what is being asked, rather than ask the same question
again using longer words. Use complete sentences. Terse writing style is
strongly discouraged.
</p></li></ul></div></div><div class="section" title="6.5.4.2.2. Boolean templates"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.4.2.2"></a>6.5.4.2.2. Boolean templates</h5></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
The short description should be phrased in the form of a question which should
be kept short and should generally end with a question mark. Terse writing
style is permitted and even encouraged if the question is rather long (remember
that translations are often longer than original versions).
</p></li><li class="listitem"><p>
Again, please avoid referring to specific interface widgets. A common mistake
for such templates is if you answer Yes-type constructions.
</p></li></ul></div></div><div class="section" title="6.5.4.2.3. Select/Multiselect"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.4.2.3"></a>6.5.4.2.3. Select/Multiselect</h5></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
The short description is a prompt and <span class="strong"><strong>not</strong></span> a
title. Do <span class="strong"><strong>not</strong></span> use useless Please choose...
constructions. Users are clever enough to figure out they have to choose
something...:)
</p></li><li class="listitem"><p>
The extended description will complete the short description. It may refer to
the available choices. It may also mention that the user may choose more than
one of the available choices, if the template is a multiselect one (although
the interface often makes this clear).
</p></li></ul></div></div><div class="section" title="6.5.4.2.4. Notes"><div class="titlepage"><div><div><h5 class="title"><a id="s6.5.4.2.4"></a>6.5.4.2.4. Notes</h5></div></div></div><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
The short description should be considered to be a <span class="strong"><strong>title</strong></span>.
</p></li><li class="listitem"><p>
The extended description is what will be displayed as a more detailed
explanation of the note. Phrases, no terse writing style.
</p></li><li class="listitem"><p>
<span class="strong"><strong>Do not abuse debconf.</strong></span> Notes are the most
common way to abuse debconf. As written in debconf-devel manual page: it's
best to use them only for warning about very serious problems. The <code class="filename">NEWS.Debian</code>
or <code class="filename">README.Debian</code> files are the appropriate location for a lot of notes. If, by
reading this, you consider converting your Note type templates to entries in
<code class="filename">NEWS.Debian</code> or <code class="filename">README.Debian</code>, plus consider keeping existing translations for
the future.
</p></li></ul></div></div></div><div class="section" title="6.5.4.3. Choices field"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.4.3"></a>6.5.4.3. Choices field</h4></div></div></div><p>
If the Choices are likely to change often, please consider using the __Choices
trick. This will split each individual choice into a single string, which will
considerably help translators for doing their work.
</p></div><div class="section" title="6.5.4.4. Default field"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.4.4"></a>6.5.4.4. Default field</h4></div></div></div><p>
If the default value, for a select template, is likely to vary depending on the
user language (for instance, if the choice is a language choice), please use
the _Default trick.
</p><p>
This special field allow translators to put the most appropriate choice
according to their own language. It will become the default choice when their
language is used while your own mentioned Default Choice will be used when
using English.
</p><p>
Example, taken from the geneweb package templates:
</p><pre class="screen">
Template: geneweb/lang
Type: select
__Choices: Afrikaans (af), Bulgarian (bg), Catalan (ca), Chinese (zh), Czech (cs), Danish (da), Dutch (nl), English (en), Esperanto (eo), Estonian (et), Finnish (fi), French (fr), German (de), Hebrew (he), Icelandic (is), Italian (it), Latvian (lv), Norwegian (no), Polish (pl), Portuguese (pt), Romanian (ro), Russian (ru), Spanish (es), Swedish (sv)
# This is the default choice. Translators may put their own language here
# instead of the default.
# WARNING : you MUST use the ENGLISH NAME of your language
# For instance, the french translator will need to put French (fr) here.
_Default: English[ translators, please see comment in PO files]
_Description: Geneweb default language:
</pre><p>
Note the use of brackets which allow internal comments in debconf fields. Also
note the use of comments which will show up in files the translators will work
with.
</p><p>
The comments are needed as the _Default trick is a bit confusing: the
translators may put their own choice
</p></div><div class="section" title="6.5.4.5. Default field"><div class="titlepage"><div><div><h4 class="title"><a id="s6.5.4.5"></a>6.5.4.5. Default field</h4></div></div></div><p>
Do NOT use empty default field. If you don't want to use default values, do
not use Default at all.
</p><p>
If you use po-debconf (and you <span class="strong"><strong>should</strong></span>, see
<a class="xref" href="best-pkging-practices.html#s6.5.2.2" title="6.5.2.2. Be kind to translators">Section 6.5.2.2, “Be kind to translators”</a>), consider making this field translatable, if you think it may be
translated.
</p><p>
If the default value may vary depending on language/country (for instance the
default value for a language choice), consider using the special _Default
type documented in <span class="citerefentry"><span class="refentrytitle">po-debconf</span>(7)</span>.
</p></div></div></div><div class="section" title="6.6. Internationalization"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-i18n"></a>6.6. Internationalization</h2></div></div></div><p>
This section contains global information for developers to make translators'
life easier. More information for translators and developers interested
in internationalization are available in the <a class="ulink" href="http://people.debian.org/~jfs/debconf6/html/" target="_top">Internationalisation and localisation in Debian</a>
documentation.
</p><div class="section" title="6.6.1. Handling debconf translations"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-i18n-debconf"></a>6.6.1. Handling debconf translations</h3></div></div></div><p>
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.
</p><p>
The goal of <code class="systemitem">debconf</code> was to make
packages configuration easier for maintainers and for users. Originally,
translation of debconf templates was handled with
<span class="command"><strong>debconf-mergetemplate</strong></span>. However, that technique is now
deprecated; the best way to accomplish <code class="systemitem">debconf</code> internationalization is by using the
<code class="systemitem">po-debconf</code> package. This method is
easier both for maintainer and translators; transition scripts are provided.
</p><p>
Using <code class="systemitem">po-debconf</code>, the translation is
stored in <code class="filename">.po</code> files (drawing from
<span class="command"><strong>gettext</strong></span> 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
<span class="command"><strong>debconf-updatepo</strong></span>, the translation is marked as needing
attention from the translators. Then, at build time, the
<span class="command"><strong>dh_installdebconf</strong></span> 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 <span class="citerefentry"><span class="refentrytitle">po-debconf</span>(7)</span> manual page for details.
</p></div><div class="section" title="6.6.2. Internationalized documentation"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-i18n-docs"></a>6.6.2. Internationalized documentation</h3></div></div></div><p>
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.
</p><p>
If you maintain documentation of any size, it is 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 <a class="ulink" href="http://svn.debian.org/wsvn/d-i/trunk/manual/scripts/doc-check?op=file" target="_top">doc-check</a> in the
<code class="systemitem">debian-installer</code> 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 VCS area.
</p><p>
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.
</p><p>
Some tools (e.g. <code class="systemitem">po4a</code>, <code class="systemitem">poxml</code>, or the <code class="systemitem">translate-toolkit</code>) are specialized in extracting
the translatable material from different formats. They produce PO files, a
format quite common to translators, which permits to see what needs to be
retranslated when the translated document is updated.
</p></div></div><div class="section" title="6.7. Common packaging situations"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="bpp-common-situations"></a>6.7. Common packaging situations</h2></div></div></div><div class="section" title="6.7.1. Packages using autoconf/automake"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-autotools"></a>6.7.1. Packages using <span class="command"><strong>autoconf</strong></span>/<span class="command"><strong>automake</strong></span></h3></div></div></div><p>
Keeping <span class="command"><strong>autoconf</strong></span>'s <code class="filename">config.sub</code> and
<code class="filename">config.guess</code> files up to date is critical for porters,
especially on more volatile architectures. Some very good packaging practices
for any package using <span class="command"><strong>autoconf</strong></span> and/or
<span class="command"><strong>automake</strong></span> have been synthesized in
<code class="filename">/usr/share/doc/autotools-dev/README.Debian.gz</code> from the
<code class="systemitem">autotools-dev</code> package. You're strongly
encouraged to read this file and to follow the given recommendations.
</p></div><div class="section" title="6.7.2. Libraries"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-libraries"></a>6.7.2. Libraries</h3></div></div></div><p>
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. Breakage in a
library can result in dozens of dependent packages breaking.
</p><p>
Good practices for library packaging have been grouped in <a class="ulink" href="http://www.netfort.gr.jp/~dancer/column/libpkg-guide/" target="_top">the library
packaging guide</a>.
</p></div><div class="section" title="6.7.3. Documentation"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-docs"></a>6.7.3. Documentation</h3></div></div></div><p>
Be sure to follow the <a class="ulink" href="http://www.debian.org/doc/debian-policy/ch-docs.html" target="_top">Policy on
documentation</a>.
</p><p>
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.
</p><p>
Policy specifies that documentation should be shipped in HTML format. We also
recommend shipping documentation in PDF and plain text format if convenient and
if output of reasonable quality is possible. However, it is generally not
appropriate to ship plain text versions of documentation whose source format is
HTML.
</p><p>
Major shipped manuals should register themselves with <code class="systemitem">doc-base</code> on installation. See the <code class="systemitem">doc-base</code> package documentation for more
information.
</p><p>
Debian policy (section 12.1) directs that manual pages should accompany every
program, utility, and function, and suggests them for other objects like
configuration files. If the work you are packaging does not have such manual
pages, consider writing them for inclusion in your package, and submitting them
upstream.
</p><p>
The manpages do not need to be written directly in the troff format. Popular
source formats are Docbook, POD and reST, which can be converted using
<span class="command"><strong>xsltproc</strong></span>, <span class="command"><strong>pod2man</strong></span> and
<span class="command"><strong>rst2man</strong></span> respectively. To a lesser extent, the
<span class="command"><strong>help2man</strong></span> program can also be used to write a stub.
</p></div><div class="section" title="6.7.4. Specific types of packages"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-other"></a>6.7.4. Specific types of packages</h3></div></div></div><p>
Several specific types of packages have special sub-policies and corresponding
packaging rules and practices:
</p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>
Perl related packages have a <a class="ulink" href="http://www.debian.org/doc/packaging-manuals/perl-policy/" target="_top">Perl
policy</a>, some examples of packages following that policy are <code class="systemitem">libdbd-pg-perl</code> (binary perl module) or <code class="systemitem">libmldbm-perl</code> (arch independent perl module).
</p></li><li class="listitem"><p>
Python related packages have their python policy; see
<code class="filename">/usr/share/doc/python/python-policy.txt.gz</code> in the <code class="systemitem">python</code> package.
</p></li><li class="listitem"><p>
Emacs related packages have the <a class="ulink" href="http://www.debian.org/doc/packaging-manuals/debian-emacs-policy" target="_top">emacs
policy</a>.
</p></li><li class="listitem"><p>
Java related packages have their <a class="ulink" href="http://www.debian.org/doc/packaging-manuals/java-policy/" target="_top">java
policy</a>.
</p></li><li class="listitem"><p>
Ocaml related packages have their own policy, found in
<code class="filename">/usr/share/doc/ocaml/ocaml_packaging_policy.gz</code> from the <code class="systemitem">ocaml</code> package. A good example is the <code class="systemitem">camlzip</code> source package.
</p></li><li class="listitem"><p>
Packages providing XML or SGML DTDs should conform to the recommendations found
in the <code class="systemitem">sgml-base-doc</code> package.
</p></li><li class="listitem"><p>
Lisp packages should register themselves with <code class="systemitem">common-lisp-controller</code>, about which see
<code class="filename">/usr/share/doc/common-lisp-controller/README.packaging</code>.
</p></li></ul></div></div><div class="section" title="6.7.5. Architecture-independent data"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-archindepdata"></a>6.7.5. Architecture-independent data</h3></div></div></div><p>
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.
</p><p>
However, if the size of the data is considerable, consider splitting it out
into a separate, architecture-independent package (<code class="filename">_all.deb</code>). 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
<code class="filename">Packages</code> files, it saves a lot of disk space on Debian
mirrors. Separating out architecture-independent data also reduces processing
time of <span class="command"><strong>lintian</strong></span> (see <a class="xref" href="tools.html#tools-lint" title="A.2. Package lint tools">Section A.2, “Package lint tools”</a>) when run over the entire Debian archive.
</p></div><div class="section" title="6.7.6. Needing a certain locale during build"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-locale"></a>6.7.6. Needing a certain locale during build</h3></div></div></div><p>
If you need a certain locale during build, you can create a temporary file via
this trick:
</p><p>
If you set <code class="varname">LOCPATH</code> to the equivalent of <code class="filename">/usr/lib/locale</code>, and <code class="varname">LC_ALL</code> to the name
of the locale you generate, you should get what you want without being root.
Something like this:
</p><pre class="screen">
LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8
mkdir -p $LOCALE_PATH
localedef -i $LOCALE_NAME.$LOCALE_CHARSET -f $LOCALE_CHARSET $LOCALE_PATH/$LOCALE_NAME.$LOCALE_CHARSET
# Using the locale
LOCPATH=$LOCALE_PATH LC_ALL=$LOCALE_NAME.$LOCALE_CHARSET date
</pre></div><div class="section" title="6.7.7. Make transition packages deborphan compliant"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-transition"></a>6.7.7. Make transition packages deborphan compliant</h3></div></div></div><p>
Deborphan is a program for helping users to detect which packages can safely be
removed from the system, i.e. the ones that have no packages depending on
them. The default operation is to search only within the libs and oldlibs
sections, to hunt down unused libraries. But when passed the right argument,
it tries to catch other useless packages.
</p><p>
For example, with <code class="literal">--guess-dummy</code>, <span class="command"><strong>deborphan</strong></span>
tries to search all transitional packages which were needed for upgrade but
which can now safely be removed.
For that, it looks for the string dummy or transitional in their short
description.
</p><p>
So, when you are creating such a package, please make sure to add this text to
your short description. If you are looking for examples, just run:
<span class="command"><strong>apt-cache search .|grep dummy</strong></span> or
<span class="command"><strong>apt-cache search .|grep transitional</strong></span>.
</p><p>
Also, it is recommended to adjust its section to
<code class="literal">oldlibs</code>
and its priority to
<code class="literal">extra</code>
in order to ease <span class="command"><strong>deborphan</strong></span>'s job.
</p></div><div class="section" title="6.7.8. Best practices for .orig.tar.{gz,bz2,xz} files"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-origtargz"></a>6.7.8. Best practices for <code class="filename">.orig.tar.{gz,bz2,xz}</code> files</h3></div></div></div><p>
There are two kinds of original source tarballs: Pristine source and repackaged
upstream source.
</p><div class="section" title="6.7.8.1. Pristine source"><div class="titlepage"><div><div><h4 class="title"><a id="pristinesource"></a>6.7.8.1. Pristine source</h4></div></div></div><p>
The defining characteristic of a pristine source tarball is that the
<code class="filename">.orig.tar.{gz,bz2,xz}</code> file is byte-for-byte identical to a tarball officially
distributed by the upstream author.<sup>[<a id="idp20127712" href="#ftn.idp20127712" class="footnote">5</a>]</sup> This makes it
possible to use checksums to easily verify that all changes between Debian's
version and upstream's are contained in the Debian diff. Also, if the original
source is huge, upstream authors and others who already have the upstream
tarball can save download time if they want to inspect your packaging in
detail.
</p><p>
There is no universally accepted guidelines that upstream authors follow
regarding to the directory structure inside their tarball, but
<span class="command"><strong>dpkg-source</strong></span> is nevertheless able to deal with most upstream
tarballs as pristine source. Its strategy is equivalent to the following:
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
It unpacks the tarball in an empty temporary directory by doing
</p><pre class="screen">
zcat path/to/<em class="replaceable"><code>packagename</code></em>_<em class="replaceable"><code>upstream-version</code></em>.orig.tar.gz | tar xf -
</pre></li><li class="listitem"><p>
If, after this, the temporary directory contains nothing but one directory and
no other files, <span class="command"><strong>dpkg-source</strong></span> renames that directory to
<code class="filename"><em class="replaceable"><code>packagename</code></em>-<em class="replaceable"><code>upstream-version</code></em>(.orig)</code>. The
name of the top-level directory in the tarball does not matter, and is
forgotten.
</p></li><li class="listitem"><p>
Otherwise, the upstream tarball must have been packaged without a common
top-level directory (shame on the upstream author!). In this case,
<span class="command"><strong>dpkg-source</strong></span> renames the temporary directory
<span class="emphasis"><em>itself</em></span> to
<code class="filename"><em class="replaceable"><code>packagename</code></em>-<em class="replaceable"><code>upstream-version</code></em>(.orig)</code>.
</p></li></ol></div></div><div class="section" title="6.7.8.2. Repackaged upstream source"><div class="titlepage"><div><div><h4 class="title"><a id="repackagedorigtargz"></a>6.7.8.2. Repackaged upstream source</h4></div></div></div><p>
You <span class="strong"><strong>should</strong></span> upload packages with a pristine
source tarball if possible, but there are various reasons why it might not be
possible. This is the case if upstream does not distribute the source as
gzipped tar at all, or if upstream's tarball contains non-DFSG-free material
that you must remove before uploading.
</p><p>
In these cases the developer must construct a suitable <code class="filename">.orig.tar.{gz,bz2,xz}</code>
file himself. We refer to such a tarball as a repackaged upstream
source. Note that a repackaged upstream source is different from a
Debian-native package. A repackaged source still comes with Debian-specific
changes in a separate <code class="filename">.diff.gz</code> or <code class="filename">.debian.tar.{gz,bz2,xz}</code>
and still has a version number composed of <em class="replaceable"><code>upstream-version</code></em> and
<em class="replaceable"><code>debian-version</code></em>.
</p><p>
There may be cases where it is desirable to repackage the source even though
upstream distributes a <code class="filename">.tar.{gz,bz2,xz}</code> that could in principle be
used in its pristine form. The most obvious is if
<span class="emphasis"><em>significant</em></span> space savings can be achieved by recompressing
the tar archive or by removing genuinely useless cruft from the upstream
archive. Use your own discretion here, but be prepared to defend your decision
if you repackage source that could have been pristine.
</p><p>
A repackaged <code class="filename">.orig.tar.{gz,bz2,xz}</code>
</p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
<span class="strong"><strong>should</strong></span> be documented in the resulting source package.
Detailed information on how the repackaged source was obtained,
and on how this can be reproduced should be provided in
<code class="filename">debian/copyright</code>. It is also a good idea to provide a
<code class="literal">get-orig-source</code> target in your
<code class="filename">debian/rules</code> file that repeats the process, as described
in the Policy Manual, <a class="ulink" href="http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules" target="_top">Main
building script: <code class="filename">debian/rules</code></a>.
</p></li><li class="listitem"><p>
<span class="strong"><strong>should not</strong></span> contain any file that does not
come from the upstream author(s), or whose contents has been changed by
you.<sup>[<a id="idp20146152" href="#ftn.idp20146152" class="footnote">6</a>]</sup>
</p></li><li class="listitem"><p>
<span class="strong"><strong>should</strong></span>, except where impossible for legal
reasons, preserve the entire building and portablility infrastructure provided
by the upstream author. For example, it is not a sufficient reason for
omitting a file that it is used only when building on MS-DOS. Similarly, a
<code class="filename">Makefile</code> provided by upstream should not be omitted even if the first thing
your <code class="filename">debian/rules</code> does is to overwrite it by running a
configure script.
</p><p>
(<span class="emphasis"><em>Rationale:</em></span> It is common for Debian users who need to
build software for non-Debian platforms to fetch the source from a Debian
mirror rather than trying to locate a canonical upstream distribution point).
</p></li><li class="listitem"><p>
<span class="strong"><strong>should</strong></span> use
<code class="filename"><em class="replaceable"><code>packagename</code></em>-<em class="replaceable"><code>upstream-version</code></em>.orig</code> as the
name of the top-level directory in its tarball. This makes it possible to
distinguish pristine tarballs from repackaged ones.
</p></li><li class="listitem"><p>
<span class="strong"><strong>should</strong></span> be gzipped or bzipped with maximal compression.
</p></li></ol></div></div><div class="section" title="6.7.8.3. Changing binary files"><div class="titlepage"><div><div><h4 class="title"><a id="changed-binfiles"></a>6.7.8.3. Changing binary files</h4></div></div></div><p>
Sometimes it is necessary to change binary files contained in the original
tarball, or to add binary files that are not in it. This is fully supported
when using source packages in “3.0 (quilt)” format, see the
<span class="citerefentry"><span class="refentrytitle">dpkg-source</span>(1)</span>
manual page for details. When using the older format “1.0”, binary files
can't be stored in the <code class="filename">.diff.gz</code> so you must store
an <span class="command"><strong>uuencode</strong></span>d (or similar) version of the file(s)
and decode it at build time in <code class="filename">debian/rules</code> (and move
it in its official location).
</p></div></div><div class="section" title="6.7.9. Best practices for debug packages"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-dbg"></a>6.7.9. Best practices for debug packages</h3></div></div></div><p>
A debug package is a package with a name ending in -dbg, that contains
additional information that <span class="command"><strong>gdb</strong></span> can use. Since Debian binaries are stripped by
default, debugging information, including function names and line numbers, is
otherwise not available when running <span class="command"><strong>gdb</strong></span> on Debian binaries. Debug packages
allow users who need this additional debugging information to install it,
without bloating a regular system with the information.
</p><p>
It is up to a package's maintainer whether to create a debug package or not.
Maintainers are encouraged to create debug packages for library packages, since
this can aid in debugging many programs linked to a library. In general, debug
packages do not need to be added for all programs; doing so would bloat the
archive. But if a maintainer finds that users often need a debugging version
of a program, it can be worthwhile to make a debug package for it. Programs
that are core infrastructure, such as apache and the X server are also good
candidates for debug packages.
</p><p>
Some debug packages may contain an entire special debugging build of a library
or other binary, but most of them can save space and build time by instead
containing separated debugging symbols that <span class="command"><strong>gdb</strong></span> can find and load on the fly
when debugging a program or library. The convention in Debian is to keep these
symbols in <code class="filename">/usr/lib/debug/<em class="replaceable"><code>path</code></em></code>, where
<em class="replaceable"><code>path</code></em> is the path to the executable or library. For
example, debugging symbols for <code class="filename">/usr/bin/foo</code> go in
<code class="filename">/usr/lib/debug/usr/bin/foo</code>, and debugging symbols for
<code class="filename">/usr/lib/libfoo.so.1</code> go in
<code class="filename">/usr/lib/debug/usr/lib/libfoo.so.1</code>.
</p><p>
The debugging symbols can be extracted from an object file using
<span class="command"><strong>objcopy --only-keep-debug</strong></span>. Then the object file can be stripped,
and <span class="command"><strong>objcopy --add-gnu-debuglink</strong></span> used to specify the path
to the debugging symbol file.
<span class="citerefentry"><span class="refentrytitle">objcopy</span>(1)</span> explains in detail how this works.
</p><p>
The <span class="command"><strong>dh_strip</strong></span> command in <code class="systemitem">debhelper</code> supports creating debug
packages, and can take care of using <span class="command"><strong>objcopy</strong></span> to separate
out the debugging symbols for you. If your package uses <code class="systemitem">debhelper</code>, all you
need to do is call <span class="command"><strong>dh_strip --dbg-package=libfoo-dbg</strong></span>, and
add an entry to <code class="filename">debian/control</code> for the debug package.
</p><p>
Note that the debug package should depend on the package that it provides
debugging symbols for, and this dependency should be versioned. For example:
</p><pre class="screen">
Depends: libfoo (= ${binary:Version})
</pre></div><div class="section" title="6.7.10. Best practices for meta-packages"><div class="titlepage"><div><div><h3 class="title"><a id="bpp-meta"></a>6.7.10. Best practices for meta-packages</h3></div></div></div><p>
A meta-package is a mostly empty package that makes it easy to install a
coherent set of packages that can evolve over time. It achieves this by
depending on all the packages of the set. Thanks to the power of APT, the
meta-package maintainer can adjust the dependencies and the user's system
will automatically get the supplementary packages. The dropped packages
that were automatically installed will be also be marked as removal
candidates (and are even automatically removed by <span class="command"><strong>aptitude</strong></span>).
<code class="systemitem">gnome</code> and
<code class="systemitem">linux-image-amd64</code> are two examples
of meta-packages (built by the source packages
<code class="systemitem">meta-gnome2</code> and
<code class="systemitem">linux-latest</code>).
</p><p>
The long description of the meta-package must clearly document its purpose
so that the user knows what he will lose if he removes the package. Being
explicit about the consequences is recommended. This is particularly
important for meta-packages which are installed during initial
installation and that have not been explicitly installed by the user.
Those tend to be important to ensure smooth system upgrades and
the user should be discouraged from uninstalling them to avoid
potential breakages.
</p></div></div><div class="footnotes"><br /><hr width="100" align="left" /><div class="footnote"><p><sup>[<a id="ftn.idp20127712" href="#idp20127712" class="para">5</a>] </sup> We cannot prevent
upstream authors from changing the tarball they distribute without also
incrementing the version number, so there can be no guarantee that a pristine
tarball is identical to what upstream <span class="emphasis"><em>currently</em></span>
distributing at any point in time. All that can be expected is that it is
identical to something that upstream once <span class="emphasis"><em>did</em></span> distribute.
If a difference arises later (say, if upstream notices that he wasn't using
maximal compression in his original distribution and then
re-<span class="command"><strong>gzip</strong></span>s it), that's just too bad. Since there is no good
way to upload a new <code class="filename">.orig.tar.{gz,bz2,xz}</code> for the same version, there is not even any
point in treating this situation as a bug. </p></div><div class="footnote"><p><sup>[<a id="ftn.idp20146152" href="#idp20146152" class="para">6</a>] </sup> As a special exception, if the omission of non-free files
would lead to the source failing to build without assistance from the Debian
diff, it might be appropriate to instead edit the files, omitting only the
non-free parts of them, and/or explain the situation in a <code class="filename">README.source</code>
file in the root of the source tree. But in that case please also urge the
upstream author to make the non-free components easier separable from the rest
of the source. </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="pkgs.html">Prev</a> </td><td width="20%" align="center"> </td><td width="40%" align="right"> <a accesskey="n" href="beyond-pkging.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 5. Managing Packages </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 7. Beyond Packaging</td></tr></table></div></body></html>
Reference in New Issue View Git Blame Copy Permalink