<?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
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>
role="package">vim</systemitem> source package is an example of how to manage
this using an hand-crafted <filename>debian/rules</filename> file.
</para>
+<!-- FIXME: Find a good debhelper example with multiple configure/make
+ cycles -->
</section>
</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:
package.
</para>
</listitem>
+<!-- FIXME: what's this?
+(the second questions is about the class of packages, and
+this about this particular package, if you have information related to both).
+-->
</itemizedlist>
</section>
<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>.
+url="&url-eg-desc-upstream-info;"></ulink>.
</para>
<para>
If there is no home page for the software, this should naturally be left out.
<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
+and <literal>&packages-host;</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.
+<filename>&packages-host;</filename> to parse it correctly.
</para>
</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">
is an example of a real NEWS.Debian 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
</section>
+<!--
+<section id="pkg-mgmt-cvs">
+<title>Managing a package with CVS</title>
+<para>
+FIXME: presentation of cvs-buildpackage, updating sources
+via CVS (debian/rules refresh).
+<ulink url="&url-devel-docs;cvs_packages">"&url-devel-docs;cvs_packages"</ulink>
+</para>
+</section>
+-->
+
<section id="bpp-debian-maint-scripts">
<title>Best practices for maintainer scripts</title>
<para>
<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>
<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>
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
<section id="bpp-common-situations">
<title>Common packaging situations</title>
+<!--
+<section id="bpp-kernel">
+<title>Kernel modules/patches</title>
+<para>
+FIXME: Heavy use of kernel-package. provide files in
+/etc/modutils/ for module configuration.
+</para>
+</section>
+-->
<section id="bpp-autotools">
<title>Packages using <command>autoconf</command>/<command>automake</command></title>
<para>
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 -->
</itemizedlist>
</section>
+<!--
+<section id="custom-config-files">
+<title>Custom configuration files</title>
+<para>
+FIXME: speak of "ucf", explain solution with a template,
+explain conf.d directories
+</para>
+</section>
+<section id="config-with-db">
+<title>Use of an external database</title>
+<para>
+FIXME: The software may require a database that you need to setup.
+But the database may be local or distant. Thus you can't depend
+on a database server but just on the corresponding library.
+
+sympa may be an example package
+</para>
+</section>
+-->
+
<section id="bpp-archindepdata">
<title>Architecture-independent data</title>
<para>
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
<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>
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>
<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>
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 README.Debian-source
+<!-- or similarly named -->
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 seperable from the rest
of the source. </para> </footnote>
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>
debugging symbols for, and this dependency should be versioned. For example:
</para>
<screen>
-: libfoo-dbg (= ${binary:Version})
+Depends: libfoo-dbg (= ${binary:Version})
</screen>
</section>