<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
- "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
+ "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
+ <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
+]>
<chapter id="best-pkging-practices">
<title>Best Packaging Practices</title>
<para>
Debian's quality is largely due to the <ulink
-url="http://www.debian.org/doc/debian-policy/">Debian Policy</ulink>, which
+url="&url-debian-policy;">Debian Policy</ulink>, 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
The rationale for using helper scripts in <filename>debian/rules</filename> 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 <filename>/usr/lib/menu</filename> (or <filename>/usr/lib/menu</filename>
+into <filename>/usr/share/menu</filename> (or <filename>/usr/lib/menu</filename>
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
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 <filename>debian/rules</filename> files are available at <ulink
-url="http://arch.debian.org/arch/private/srivasta/"></ulink>.
+url="&url-rules-files;"></ulink>.
</para>
</section>
<para>
The following practices are relevant to the <filename>debian/control</filename>
file. They supplement the <ulink
-url="http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions">Policy
+url="&url-debian-policy;ch-binary.html#s-descriptions">Policy
on package descriptions</ulink>.
</para>
<para>
</para>
<para>
If you are having problems writing your description, you may wish to send it
-along to <email>debian-l10n-english@lists.debian.org</email> and request
-feedback.
+along to &email-debian-l10n-english; and request feedback.
</para>
</section>
modes for checking <filename>debian/control</filename> files:
</para>
<screen>
- -d american -g debian/control
+ispell -d american -g debian/control
</screen>
<screen>
- -d en -D -c debian/control
+aspell -d en -D -c debian/control
</screen>
<para>
Users usually expect these questions to be answered in the package description:
</listitem>
<listitem>
<para>
-If the package is experimental, 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.
+If the package is <literal>experimental</literal>, 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.
</para>
</listitem>
<listitem>
<section id="bpp-upstream-info">
<title>Upstream home page</title>
<para>
-We recommend that you add the URL for the package's home page to the package
-description in <filename>debian/control</filename>. This information should be
-added at the end of description, using the following format:
-</para>
-<screen>
- .
- Homepage: http://some-project.some-place.org/
-</screen>
-<para>
-Note the spaces prepending the line, which serves to break the lines correctly.
-To see an example of how this displays, see <ulink
-url="http://packages.debian.org/unstable/web/wml"></ulink>.
-</para>
-<para>
-If there is no home page for the software, this should naturally be left out.
-</para>
-<para>
-Note that we expect this field will eventually be replaced by a proper
-<filename>debian/control</filename> field understood by <command>dpkg</command>
-and <literal>packages.debian.org</literal>. If you don't want to bother
-migrating the home page from the description to this field, you should probably
-wait until that is available. Please make sure that this line matches the
-regular expression <literal>/^ Homepage: [^ ]*$/</literal>, as this allows
-<filename>packages.debian.org</filename> to parse it correctly.
+We recommend that you add the URL for the package's home page in the
+<literal>Homepage</literal> field of the <literal>Source</literal> section
+in <filename>debian/control</filename>. Adding this information in the
+package description itself is considered deprecated.
</para>
</section>
<filename>debian/control</filename>.
</para>
<section id="s6.2.5.1">
-<title>XS-Vcs-Browser</title>
+<title>Vcs-Browser</title>
<para>
Value of this field should be a <literal>http://</literal> URL pointing to a
web-browsable copy of the Version Control System repository used to maintain
</section>
<section id="s6.2.5.2">
-<title>XS-Vcs-*</title>
+<title>Vcs-*</title>
<para>
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
the URL is in the <literal>svn://</literal> scheme (instead of
<literal>svn+ssh://</literal>) and how it points to the
<filename>trunk/</filename> branch. The use of the
-<literal>XS-Vcs-Browser</literal> field described above is also shown.
+<literal>Vcs-Browser</literal> and <literal>Homepage</literal> fields
+described above is also shown.
</para>
<screen>
Source: vim
Section: editors
Priority: optional
<snip>
- XS-Vcs-Svn: svn://svn.debian.org/svn/pkg-vim/trunk/packages/vim
- XS-Vcs-Browser: http://svn.debian.org/wsvn/pkg-vim/trunk/packages/vim
+ 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
</screen>
</section>
<title>Best practices for <filename>debian/changelog</filename></title>
<para>
The following practices supplement the <ulink
-url="http://www.debian.org/doc/debian-policy/ch-docs.html#s-changelogs">Policy
+url="&url-debian-policy;ch-docs.html#s-changelogs">Policy
on changelog files</ulink>.
</para>
<section id="bpp-changelog-do">
<section id="bpp-news-debian">
<title>Supplementing changelogs with NEWS.Debian files</title>
<para>
-Important news about changes in a package can also be put in NEWS.Debian files.
+Important news about changes in a package can also be put in <filename>
+NEWS.Debian</filename> files.
The news will be displayed by tools like apt-listchanges, 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 debconf notes since
-it is less annoying and the user can go back and refer to the NEWS.Debian file
-after the install. And it's better than listing major changes in
-README.Debian, since the user can easily miss such notes.
+it is less annoying and the user can go back and refer to the <filename>
+NEWS.Debian</filename> file after the install. And it's better than listing
+major changes in <filename>README.Debian</filename>, since the user can easily
+miss such notes.
</para>
<para>
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 dpkg-parsechangelog to check its formatting
-as it will not be automatically checked during build as the changelog is. Here
-is an example of a real NEWS.Debian file:
+good idea to run your file through <literal>dpkg-parsechangelog</literal> to
+check its formatting as it will not be automatically checked during build as
+the changelog is. Here is an example of a real <filename>NEWS.Debian
+</filename> file:
</para>
<screen>
- (3.0pl1-74) unstable; urgency=low
+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
-- Steve Greenland <stevegr@debian.org> Sat, 6 Sep 2003 17:15:03 -0500
</screen>
<para>
-The NEWS.Debian file is installed as
-/usr/share/doc/<package>/NEWS.Debian.gz. It is compressed, and always
-has that name even in Debian native packages. If you use debhelper,
-dh_installchangelogs will install debian/NEWS files for you.
+The <filename>NEWS.Debian</filename> file is installed as <filename>
+/usr/share/doc/<replaceable>package</replaceable>/NEWS.Debian.gz</filename>.
+It is compressed, and always has that name even in Debian native packages.
+If you use <literal>debhelper</literal>, <literal>dh_installchangelogs
+</literal> will install <filename>debian/NEWS</filename> files for you.
</para>
<para>
-Unlike changelog files, you need not update NEWS.Debian 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
-NEWS.Debian file in your package. No news is good news!
+Unlike changelog files, you need not update <filename>NEWS.Debian</filename>
+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 <filename>NEWS.Debian</filename> file in your package. No news
+is good news!
</para>
</section>
<para>
FIXME: presentation of cvs-buildpackage, updating sources
via CVS (debian/rules refresh).
-<ulink url="http://www.debian.org/devel/cvs_packages">"http://www.debian.org/devel/cvs_packages"</ulink>
+<ulink url="&url-devel-docs;cvs_packages">"&url-devel-docs;cvs_packages"</ulink>
</para>
</section>
-->
<filename>debian/postrm</filename>. 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
-<ulink url="http://www.debian.org/doc/debian-policy/">Debian Policy</ulink>.
+<ulink url="&url-debian-policy;">Debian Policy</ulink>.
</para>
<para>
Maintainer scripts must be idempotent. That means that you need to make sure
If you need to check for the existence of a command, you should use something
like
</para>
-<screen>
- [ -x /usr/sbin/install-docs ]; then ...
-</screen>
+<programlisting>if [ -x /usr/sbin/install-docs ]; then ...</programlisting>
<para>
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:
</para>
-<screen>
-() {
- OLDIFS=$IFS
- IFS=:
- for p in $PATH; do
- if [ -x $p/$* ]; then
- IFS=$OLDIFS
- return 0
- fi
- done
- IFS=$OLDIFS
- return 1
-}
-</screen>
+&example-pathfind;
<para>
You can use this function to search <literal>$PATH</literal> for a command
name, passed as an argument. It returns true (zero) if the command was found,
properly phrased templates may not be easy for them.
</para>
<para>
-Please use (and abuse) <email>debian-l10n-english@lists.debian.org</email>
-mailing list. Have your templates proofread.
+Please use (and abuse) &email-debian-l10n-english; mailing
+list. Have your templates proofread.
</para>
<para>
Badly written templates give a poor image of your package, of your work...or
<para>
Please use gettext-based templates. Install <systemitem
role="package">po-debconf</systemitem> on your development system and read its
-documentation (man po-debconf is a good start).
+documentation (<literal>man po-debconf</literal> is a good start).
</para>
<para>
Avoid changing templates too often. Changing templates text induces more work
files headers.
</para>
<para>
-The use of the <command>podebconf-report-po</command> from the po-debconf
-package is highly recommended to warn translators which have incomplete
-translations and request them for updates.
+The use of the <command>podebconf-report-po</command> from the <systemitem
+role="package">po-debconf</systemitem> package is highly recommended to warn
+translators which have incomplete translations and request them for updates.
</para>
<para>
If in doubt, you may also contact the translation team for a given language
-(debian-l10n-xxxxx@lists.debian.org), or the
-<email>debian-i18n@lists.debian.org</email> mailing list.
+(debian-l10n-xxxxx@&lists-host;), or the
+&email-debian-i18n; mailing list.
</para>
<para>
-Calls for translations posted to <email>debian-i18n@lists.debian.org</email>
-with the <filename>debian/po/templates.pot</filename> file attached or
-referenced in a URL are encouraged. Be sure to mentions in these calls for new
-translations which languages you have existing translations for, in order to
-avoid duplicate work.
+Calls for translations posted to &email-debian-i18n; with the
+<filename>debian/po/templates.pot</filename> file attached or referenced in a
+URL are encouraged. Be sure to mentions in these calls for new translations
+which languages you have existing translations for, in order to avoid duplicate
+work.
</para>
</section>
translator will send you an update.
</para>
<para>
-To <emphasis role="strong">unfuzzy</emphasis> translations, you can proceed the
+To <literal>unfuzzy</literal> translations, you can proceed the
following way:
</para>
<orderedlist numeration="arabic">
using (needs the <systemitem role="package">gettext</systemitem> package
installed):
</para>
-<screen>
- i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
---statistics $i; done
-</screen>
+<programlisting>for i in debian/po/*po; do echo -n $i: ; msgfmt -o /dev/null
+--statistics $i; done</programlisting>
</listitem>
<listitem>
<para>
<para>
use the following command:
</para>
-<screen>
- i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done
-</screen>
+<programlisting>for i in debian/po/*po; do msgattrib --output-file=$i --clear-fuzzy $i; done</programlisting>
</listitem>
<listitem>
<para>
Example, taken from the geneweb package templates:
</para>
<screen>
-: geneweb/lang
+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
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 <ulink
-url="http://cvs.debian.org/boot-floppies/documentation/doc-check?rev=HEAD\|[amp
-]\|content-type=text/vnd.viewcvs-markup">doc-check</ulink> in the <systemitem
-role="package">boot-floppies</systemitem> package, which shows an overview of
-the translation status for any given language, using structured comments for
-the current revision of the file to be translated and, for a translated file,
-the revision of the original file the translation is based on. You might wish
-to adapt and provide that in your CVS area.
+url="&url-i18n-doc-check;">doc-check</ulink> in the
+<systemitem role="package">boot-floppies</systemitem> package, which shows an
+overview of the translation status for any given language, using structured
+comments for the current revision of the file to be translated and, for a
+translated file, the revision of the original file the translation is based on.
+You might wish to adapt and provide that in your CVS area.
</para>
<para>
If you maintain XML or SGML documentation, we suggest that you isolate any
especially on more volatile architectures. Some very good packaging practices
for any package using <command>autoconf</command> and/or
<command>automake</command> have been synthesized in
-<filename>/usr/share/doc/autotools-dev/README.Debian.gz</filename> from the
+&file-bpp-autotools; from the
<systemitem role="package">autotools-dev</systemitem> package. You're strongly
encouraged to read this file and to follow the given recommendations.
</para>
</para>
<para>
Good practices for library packaging have been grouped in <ulink
-url="http://www.netfort.gr.jp/~dancer/column/libpkg-guide/">the library
+url="&url-libpkg-guide;">the library
packaging guide</ulink>.
</para>
</section>
<title>Documentation</title>
<para>
Be sure to follow the <ulink
-url="http://www.debian.org/doc/debian-policy/ch-docs.html">Policy on
+url="&url-debian-policy;ch-docs.html">Policy on
documentation</ulink>.
</para>
<para>
<listitem>
<para>
Perl related packages have a <ulink
-url="http://www.debian.org/doc/packaging-manuals/perl-policy/">Perl
+url="&url-perl-policy;">Perl
policy</ulink>, some examples of packages following that policy are <systemitem
role="package">libdbd-pg-perl</systemitem> (binary perl module) or <systemitem
role="package">libmldbm-perl</systemitem> (arch independent perl module).
<listitem>
<para>
Python related packages have their python policy; see
-<filename>/usr/share/doc/python/python-policy.txt.gz</filename> in the
-<systemitem role="package">python</systemitem> package.
+&file-python-policy; in the <systemitem
+role="package">python</systemitem> package.
</para>
</listitem>
<listitem>
<para>
Emacs related packages have the <ulink
-url="http://www.debian.org/doc/packaging-manuals/debian-emacs-policy">emacs
+url="&url-emacs-policy;">emacs
policy</ulink>.
</para>
</listitem>
<listitem>
<para>
Java related packages have their <ulink
-url="http://www.debian.org/doc/packaging-manuals/java-policy/">java
+url="&url-java-policy;">java
policy</ulink>.
</para>
</listitem>
<listitem>
<para>
Ocaml related packages have their own policy, found in
-<filename>/usr/share/doc/ocaml/ocaml_packaging_policy.gz</filename> from the
-<systemitem role="package">ocaml</systemitem> package. A good example is the
-<systemitem role="package">camlzip</systemitem> source package.
+&file-ocaml-policy; from the <systemitem
+role="package">ocaml</systemitem> package. A good example is the <systemitem
+role="package">camlzip</systemitem> source package.
</para>
</listitem>
<listitem>
<para>
Lisp packages should register themselves with <systemitem
role="package">common-lisp-controller</systemitem>, about which see
-<filename>/usr/share/doc/common-lisp-controller/README.packaging</filename>.
+&file-lisp-controller;.
</para>
</listitem>
<!-- TODO: mozilla extension policy, once that becomes available -->
per each architecture. While this adds some extra overhead into the
<filename>Packages</filename> files, it saves a lot of disk space on Debian
mirrors. Separating out architecture-independent data also reduces processing
-time of <command>lintian</command> or <command>linda</command> (see <xref
+time of <command>lintian</command> (see <xref
linkend="tools-lint"/> ) when run over the entire Debian archive.
</para>
</section>
this trick:
</para>
<para>
-If you set LOCPATH to the equivalent of /usr/lib/locale, and LC_ALL to the name
+If you set <varname>LOCPATH</varname> to the equivalent of <filename>/usr/lib/locale</filename>, and <varname>LC_ALL</varname> to the name
of the locale you generate, you should get what you want without being root.
Something like this:
</para>
<screen>
-=debian/tmpdir/usr/lib/locale
+LOCALE_PATH=debian/tmpdir/usr/lib/locale
LOCALE_NAME=en_IN
LOCALE_CHARSET=UTF-8
it tries to catch other useless packages.
</para>
<para>
-For example, with --guess-dummy, deborphan tries to search all transitional
-packages which were needed for upgrade but which can now safely be removed.
+For example, with <literal>--guess-dummy</literal>, <command>deborphan</command>
+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.
</para>
<para>
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:
-</para>
-<screen>
--cache search .|grep dummy
-</screen>
-<para>
-or
-</para>
-<screen>
--cache search .|grep transitional
-</screen>
-<para>
-.
+<command>apt-cache search .|grep dummy</command> or
+<command>apt-cache search .|grep transitional</command>.
</para>
</section>
<title>Pristine source</title>
<para>
The defining characteristic of a pristine source tarball is that the
-.orig.tar.gz file is byte-for-byte identical to a tarball officially
+<literal>.orig.tar.gz</literal> file is byte-for-byte identical to a tarball officially
distributed by the upstream author. <footnote><para> 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
identical to something that upstream once <emphasis>did</emphasis> distribute.
If a difference arises later (say, if upstream notices that he wasn't using
maximal comression in his original distribution and then
-re-<literal>gzip</literal>s it), that's just too bad. Since there is no good
-way to upload a new .orig.tar.gz for the same version, there is not even any
+re-<command>gzip</command>s it), that's just too bad. Since there is no good
+way to upload a new <literal>.orig.tar.gz</literal> for the same version, there is not even any
point in treating this situation as a bug. </para> </footnote> 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
It unpacks the tarball in an empty temporary directory by doing
</para>
<screen>
- path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
+zcat path/to/<packagename>_<upstream-version>.orig.tar.gz | tar xf -
</screen>
</listitem>
<listitem>
that you must remove before uploading.
</para>
<para>
-In these cases the developer must construct a suitable .orig.tar.gz 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
-<literal>.diff.gz</literal> and still has a version number composed of
-<literal><upstream-version></literal> and
+In these cases the developer must construct a suitable <literal>.orig.tar.gz
+</literal> 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 <literal>.diff.gz</literal> and still has a version
+number composed of <literal><upstream-version></literal> and
<literal><debian-revision></literal>.
</para>
<para>
if you repackage source that could have been pristine.
</para>
<para>
-A repackaged .orig.tar.gz
+A repackaged <literal>.orig.tar.gz</literal>
</para>
<orderedlist numeration="arabic">
<listitem>
<literal>get-orig-source</literal> target in your
<filename>debian/rules</filename> file that repeats the process, as described
in the Policy Manual, <ulink
-url="http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules">Main
+url="&url-debian-policy;ch-source.html#s-debianrules">Main
building script: debian/rules</ulink>.
</para>
</listitem>
Note that you don't need to depend on <systemitem
role="package">sharutils</systemitem> to get the <command>uudecode</command>
program if you use <command>perl</command>'s <literal>pack</literal> function.
-The code could look like </para> <screen> -file: perl -ne 'print(pack u, $$_);'
-$(file) > $(file).uuencoded uudecode-file: perl -ne 'print(unpack u, $$_);'
-$(file).uuencoded > $(file) </screen> </footnote>. The file would then be
+The code could look like
+</para>
+&example-uu;
+</footnote>. The file would then be
decoded and copied to its place during the build process. Thus the change will
be visible quite easy.
</para>
or other binary, but most of them can save space and build time by instead
containing separated debugging symbols that gdb can find and load on the fly
when debugging a program or library. The convention in Debian is to keep these
-symbols in <filename>/usr/lib/debug/path</filename>, where
-<emphasis>path</emphasis> is the path to the executable or library. For
+symbols in <filename>/usr/lib/debug/<replaceable>path</replaceable></filename>, where
+<replaceable>path</replaceable> is the path to the executable or library. For
example, debugging symbols for <filename>/usr/bin/foo</filename> go in
<filename>/usr/lib/debug/usr/bin/foo</filename>, and debugging symbols for
<filename>/usr/lib/libfoo.so.1</filename> go in
<filename>/usr/lib/debug/usr/lib/libfoo.so.1</filename>.
</para>
<para>
-The debugging symbols can be extracted from an object file using objcopy
---only-keep-debug. Then the object file can be stripped, and objcopy
---add-gnu-debuglink used to specify the path to the debugging symbol file.
+The debugging symbols can be extracted from an object file using <command>
+objcopy --only-keep-debug</command>. Then the object file can be stripped,
+and <command>objcopy --add-gnu-debuglink</command> used to specify the path
+to the debugging symbol file.
<citerefentry> <refentrytitle>objcopy</refentrytitle> <manvolnum>1</manvolnum>
</citerefentry> explains in detail how this works.
</para>
<para>
-The dh_strip command in debhelper supports creating debug packages, and can
-take care of using objcopy to separate out the debugging symbols for you. If
-your package uses debhelper, all you need to do is call dh_strip
---dbg-package=libfoo-dbg, and add an entry to debian/control for the debug
-package.
+The <command>dh_strip</command> command in debhelper supports creating debug
+packages, and can take care of using <command>objcopy</command> to separate
+out the debugging symbols for you. If your package uses debhelper, all you
+need to do is call <command>dh_strip --dbg-package=libfoo-dbg</command>, and
+add an entry to <filename>debian/control</filename> for the debug package.
</para>
<para>
Note that the Debian package should depend on the package that it provides
debugging symbols for, and this dependency should be versioned. For example:
</para>
<screen>
-: libfoo-dbg (= ${binary:Version})
+Depends: libfoo-dbg (= ${binary:Version})
</screen>
</section>
~ianmdlvl / developers-reference.git / blobdiff