Put in place the new developers-reference and the new refcard.

[developers-reference.git] / tools.dbk

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE appendix PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
    "http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd" [
  <!ENTITY % commondata SYSTEM "common.ent" > %commondata;
]>
<appendix id="tools">
<title>Overview of Debian Maintainer Tools</title>
<para>
This section contains a rough overview of the tools available to maintainers.
The following is by no means complete or definitive, but just a guide to some
of the more popular tools.
</para>
<para>
Debian maintainer tools are meant to aid developers and free their time for
critical tasks.  As Larry Wall says, there's more than one way to do it.
</para>
<para>
Some people prefer to use high-level package maintenance tools and some do not.
Debian is officially agnostic on this issue; any tool which gets the job done
is fine.  Therefore, this section is not meant to stipulate to anyone which
tools they should use or how they should go about their duties of
maintainership.  Nor is it meant to endorse any particular tool to the
exclusion of a competing tool.
</para>
<para>
Most of the descriptions of these packages come from the actual package
descriptions themselves.  Further information can be found in the package
documentation itself.  You can also see more info with the command
<command>apt-cache show &lt;package-name&gt;</command>.
</para>
<section id="tools-core">
<title>Core tools</title>
<para>
The following tools are pretty much required for any maintainer.
</para>
<section id="dpkg-dev">
<title><systemitem role="package">dpkg-dev</systemitem></title>
<para>
<systemitem role="package">dpkg-dev</systemitem> contains the tools (including
<command>dpkg-source</command>) required to unpack, build, and upload Debian
source packages.  These utilities contain the fundamental, low-level
functionality required to create and manipulate packages; as such, they are
essential for any Debian maintainer.
</para>
</section>

<section id="debconf">
<title><systemitem role="package">debconf</systemitem></title>
<para>
<systemitem role="package">debconf</systemitem> provides a consistent interface
to configuring packages interactively.  It is user interface independent,
allowing end-users to configure packages with a text-only interface, an HTML
interface, or a dialog interface.  New interfaces can be added as modules.
</para>
<para>
You can find documentation for this package in the <systemitem
role="package">debconf-doc</systemitem> package.
</para>
<para>
Many feel that this system should be used for all packages which require
interactive configuration; see <xref linkend="bpp-config-mgmt"/> .  <systemitem
role="package">debconf</systemitem> is not currently required by Debian Policy,
but that may change in the future.
</para>
</section>

<section id="fakeroot">
<title><systemitem role="package">fakeroot</systemitem></title>
<para>
<systemitem role="package">fakeroot</systemitem> simulates root privileges.
This enables you to build packages without being root (packages usually want to
install files with root ownership).  If you have <systemitem
role="package">fakeroot</systemitem> installed, you can build packages as a
regular user: <literal>dpkg-buildpackage -rfakeroot</literal>.
</para>
</section>

</section>

<section id="tools-lint">
<title>Package lint tools</title>
<para>
According to the Free On-line Dictionary of Computing (FOLDOC), `lint' is a
Unix C language processor which carries out more thorough checks on the code
than is usual with C compilers.  Package lint tools help package maintainers by
automatically finding common problems and policy violations in their packages.
</para>
<section id="lintian">
<title><systemitem role="package">lintian</systemitem></title>
<para>
<systemitem role="package">lintian</systemitem> dissects Debian packages and
emits information about bugs and policy violations.  It contains automated
checks for many aspects of Debian policy as well as some checks for common
errors.
</para>
<para>
You should periodically get the newest <systemitem
role="package">lintian</systemitem> from `unstable' and check over all your
packages.  Notice that the <literal>-i</literal> option provides detailed
explanations of what each error or warning means, what its basis in Policy is,
and commonly how you can fix the problem.
</para>
<para>
Refer to <xref linkend="sanitycheck"/> for more information on how and when to
use Lintian.
</para>
<para>
You can also see a summary of all problems reported by Lintian on your packages
at <ulink url="&url-lintian;"></ulink>.  These reports contain the
latest <command>lintian</command> output for the whole development distribution
(unstable).
</para>
</section>

<section id="linda">
<title><systemitem role="package">linda</systemitem></title>
<para>
<systemitem role="package">linda</systemitem> is another package linter.  It is
similar to <systemitem role="package">lintian</systemitem> but has a different
set of checks.  Its written in Python rather than Perl.
</para>
</section>

<section id="debdiff">
<title><systemitem role="package">debdiff</systemitem></title>
<para>
<command>debdiff</command> (from the <systemitem
role="package">devscripts</systemitem> package, <xref linkend="devscripts"/> )
compares file lists and control files of two packages.  It is a simple
regression test, as it will help you notice if the number of binary packages
has changed since the last upload, or if something has changed in the control
file.  Of course, some of the changes it reports will be all right, but it can
help you prevent various accidents.
</para>
<para>
You can run it over a pair of binary packages:
</para>
<screen>
debdiff package_1-1_arch.deb package_2-1_arch.deb
</screen>
<para>
Or even a pair of changes files:
</para>
<screen>
debdiff package_1-1_arch.changes package_2-1_arch.changes
</screen>
<para>
For more information please see <citerefentry>
<refentrytitle>debdiff</refentrytitle> <manvolnum>1</manvolnum>
</citerefentry>.
</para>
</section>

</section>

<section id="tools-helpers">
<title>Helpers for <filename>debian/rules</filename></title>
<para>
Package building tools make the process of writing
<filename>debian/rules</filename> files easier.  See <xref
linkend="helper-scripts"/> for more information about why these might or might
not be desired.
</para>
<section id="debhelper">
<title><systemitem role="package">debhelper</systemitem></title>
<para>
<systemitem role="package">debhelper</systemitem> is a collection of programs
which can be used in <filename>debian/rules</filename> to automate common tasks
related to building binary Debian packages.  <systemitem
role="package">debhelper</systemitem> includes programs to install various
files into your package, compress files, fix file permissions, and integrate
your package with the Debian menu system.
</para>
<para>
Unlike some approaches, <systemitem role="package">debhelper</systemitem> is
broken into several small, simple commands which act in a consistent manner.
As such, it allows more fine-grained control than some of the other
debian/rules tools.
</para>
<para>
There are a number of little <systemitem role="package">debhelper</systemitem>
add-on packages, too transient to document.  You can see the list of most of
them by doing <literal>apt-cache search ^dh-</literal>.
</para>
</section>

<section id="debmake">
<title><systemitem role="package">debmake</systemitem></title>
<para>
<systemitem role="package">debmake</systemitem>, a precursor to <systemitem
role="package">debhelper</systemitem>, is a more coarse-grained
<filename>debian/rules</filename> assistant.  It includes two main programs:
<command>deb-make</command>, which can be used to help a maintainer convert a
regular (non-Debian) source archive into a Debian source package; and
<command>debstd</command>, which incorporates in one big shot the same sort of
automated functions that one finds in <systemitem
role="package">debhelper</systemitem>.
</para>
<para>
The consensus is that <systemitem role="package">debmake</systemitem> is now
deprecated in favor of <systemitem role="package">debhelper</systemitem>.  It
is a bug to use <systemitem role="package">debmake</systemitem> in new
packages.  New packages using <systemitem role="package">debmake</systemitem>
will be rejected from the archive.
</para>
</section>

<section id="dh-make">
<title><systemitem role="package">dh-make</systemitem></title>
<para>
The <systemitem role="package">dh-make</systemitem> package contains
<command>dh_make</command>, a program that creates a skeleton of files
necessary to build a Debian package out of a source tree.  As the name
suggests, <command>dh_make</command> is a rewrite of <systemitem
role="package">debmake</systemitem> and its template files use dh_* programs
from <systemitem role="package">debhelper</systemitem>.
</para>
<para>
While the rules files generated by <command>dh_make</command> are in general a
sufficient basis for a working package, they are still just the groundwork: the
burden still lies on the maintainer to finely tune the generated files and make
the package entirely functional and Policy-compliant.
</para>
</section>

<section id="yada">
<title><systemitem role="package">yada</systemitem></title>
<para>
<systemitem role="package">yada</systemitem> is another packaging helper tool.
It uses a <filename>debian/packages</filename> file to auto-generate
<filename>debian/rules</filename> and other necessary files in the
<filename>debian/</filename> subdirectory.  The
<filename>debian/packages</filename> file contains instruction to build
packages and there is no need to create any <filename>Makefile</filename>
files.  There is possibility to use macro engine similar to the one used in
SPECS files from RPM source packages.
</para>
<para>
For more informations see <literal><ulink
url="http://yada.alioth.debian.org/">YADA site</ulink></literal>.
</para>
</section>

<section id="equivs">
<title><systemitem role="package">equivs</systemitem></title>
<para>
<systemitem role="package">equivs</systemitem> is another package for making
packages.  It is often suggested for local use if you need to make a package
simply to fulfill dependencies.  It is also sometimes used when making
``meta-packages'', which are packages whose only purpose is to depend on other
packages.
</para>
</section>

</section>

<section id="tools-builders">
<title>Package builders</title>
<para>
The following packages help with the package building process, general driving
<command>dpkg-buildpackage</command> as well as handling supporting tasks.
</para>
<section id="cvs-buildpackage">
<title><systemitem role="package">cvs-buildpackage</systemitem></title>
<para>
<systemitem role="package">cvs-buildpackage</systemitem> provides the
capability to inject or import Debian source packages into a CVS repository,
build a Debian package from the CVS repository, and helps in integrating
upstream changes into the repository.
</para>
<para>
These utilities provide an infrastructure to facilitate the use of CVS by
Debian maintainers.  This allows one to keep separate CVS branches of a package
for <emphasis>stable</emphasis>, <emphasis>unstable</emphasis> and possibly
<emphasis>experimental</emphasis> distributions, along with the other benefits
of a version control system.
</para>
</section>

<section id="debootstrap">
<title><systemitem role="package">debootstrap</systemitem></title>
<para>
The <systemitem role="package">debootstrap</systemitem> package and script
allows you to bootstrap a Debian base system into any part of your filesystem.
By base system, we mean the bare minimum of packages required to operate and
install the rest of the system.
</para>
<para>
Having a system like this can be useful in many ways.  For instance, you can
<command>chroot</command> into it if you want to test your build dependencies.
Or you can test how your package behaves when installed into a bare base
system.  Chroot builders use this package; see below.
</para>
</section>

<section id="pbuilder">
<title><systemitem role="package">pbuilder</systemitem></title>
<para>
<systemitem role="package">pbuilder</systemitem> constructs a chrooted system,
and builds a package inside the chroot.  It is very useful to check that a
package's build-dependencies are correct, and to be sure that unnecessary and
wrong build dependencies will not exist in the resulting package.
</para>
<para>
A related package is <systemitem role="package">pbuilder-uml</systemitem>,
which goes even further by doing the build within a User Mode Linux
environment.
</para>
</section>

<section id="sbuild">
<title><systemitem role="package">sbuild</systemitem></title>
<para>
<systemitem role="package">sbuild</systemitem> is another automated builder.
It can use chrooted environments as well.  It can be used stand-alone, or as
part of a networked, distributed build environment.  As the latter, it is part
of the system used by porters to build binary packages for all the available
architectures.  See <xref linkend="buildd"/> for more information, and <ulink
url="&url-buildd;"></ulink> to see the system in action.
</para>
</section>

</section>

<section id="uploaders">
<title>Package uploaders</title>
<para>
The following packages help automate or simplify the process of uploading
packages into the official archive.
</para>
<section id="dupload">
<title><systemitem role="package">dupload</systemitem></title>
<para>
<systemitem role="package">dupload</systemitem> is a package and a script to
automatically upload Debian packages to the Debian archive, to log the upload,
and to send mail about the upload of a package.  You can configure it for new
upload locations or methods.
</para>
</section>

<section id="dput">
<title><systemitem role="package">dput</systemitem></title>
<para>
The <systemitem role="package">dput</systemitem> package and script does much
the same thing as <systemitem role="package">dupload</systemitem>, but in a
different way.  It has some features over <systemitem
role="package">dupload</systemitem>, such as the ability to check the GnuPG
signature and checksums before uploading, and the possibility of running
<command>dinstall</command> in dry-run mode after the upload.
</para>
</section>

<section id="dcut">
<title><systemitem role="package">dcut</systemitem></title>
<para>
The <systemitem role="package">dcut</systemitem> script (part of the package
<xref linkend="dput"/> ) helps in removing files from the ftp upload directory.
</para>
</section>

</section>

<section id="tools-maint-automate">
<title>Maintenance automation</title>
<para>
The following tools help automate different maintenance tasks, from adding
changelog entries or signature lines and looking up bugs in Emacs to making use
of the newest and official <filename>config.sub</filename>.
</para>
<section id="devscripts">
<title><systemitem role="package">devscripts</systemitem></title>
<para>
<systemitem role="package">devscripts</systemitem> is a package containing
wrappers and tools which are very helpful for maintaining your Debian packages.
Example scripts include <command>debchange</command> and
<command>dch</command>, which manipulate your
<filename>debian/changelog</filename> file from the command-line, and
<command>debuild</command>, which is a wrapper around
<command>dpkg-buildpackage</command>.  The <command>bts</command> utility is
also very helpful to update the state of bug reports on the command line.
<command>uscan</command> can be used to watch for new upstream versions of your
packages.  <command>debrsign</command> can be used to remotely sign a package
prior to upload, which is nice when the machine you build the package on is
different from where your GPG keys are.
</para>
<para>
See the <citerefentry> <refentrytitle>devscripts</refentrytitle>
<manvolnum>1</manvolnum> </citerefentry> manual page for a complete list of
available scripts.
</para>
</section>

<section id="autotools-dev">
<title><systemitem role="package">autotools-dev</systemitem></title>
<para>
<systemitem role="package">autotools-dev</systemitem> contains best practices
for people who maintain packages which use <command>autoconf</command> and/or
<command>automake</command>.  Also contains canonical
<filename>config.sub</filename> and <filename>config.guess</filename> files
which are known to work on all Debian ports.
</para>
</section>

<section id="dpkg-repack">
<title><systemitem role="package">dpkg-repack</systemitem></title>
<para>
<command>dpkg-repack</command> creates Debian package file out of a package
that has already been installed.  If any changes have been made to the package
while it was unpacked (e.g., files in <filename>/etc</filename> were modified),
the new package will inherit the changes.
</para>
<para>
This utility can make it easy to copy packages from one computer to another, or
to recreate packages which are installed on your system but no longer available
elsewhere, or to save the current state of a package before you upgrade it.
</para>
</section>

<section id="alien">
<title><systemitem role="package">alien</systemitem></title>
<para>
<command>alien</command> converts binary packages between various packaging
formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris,
and Slackware packages.
</para>
</section>

<section id="debsums">
<title><systemitem role="package">debsums</systemitem></title>
<para>
<command>debsums</command> checks installed packages against their MD5 sums.
Note that not all packages have MD5 sums, since they aren't required by Policy.
</para>
</section>

<section id="dpkg-dev-el">
<title><systemitem role="package">dpkg-dev-el</systemitem></title>
<para>
<systemitem role="package">dpkg-dev-el</systemitem> is an Emacs lisp package
which provides assistance when editing some of the files in the
<filename>debian</filename> directory of your package.  For instance, there are
handy functions for listing a package's current bugs, and for finalizing the
latest entry in a <filename>debian/changelog</filename> file.
</para>
</section>

<section id="dpkg-depcheck">
<title><systemitem role="package">dpkg-depcheck</systemitem></title>
<para>
<command>dpkg-depcheck</command> (from the <systemitem
role="package">devscripts</systemitem> package, <xref linkend="devscripts"/> )
runs a command under <command>strace</command> to determine all the packages
that were used by the said command.
</para>
<para>
For Debian packages, this is useful when you have to compose a
<literal>Build-Depends</literal> line for your new package: running the build
process through <command>dpkg-depcheck</command> will provide you with a good
first approximation of the build-dependencies.  For example:
</para>
<screen>
dpkg-depcheck -b debian/rules build
</screen>
<para>
<command>dpkg-depcheck</command> can also be used to check for run-time
dependencies, especially if your package uses exec(2) to run other programs.
</para>
<para>
For more information please see <citerefentry>
<refentrytitle>dpkg-depcheck</refentrytitle> <manvolnum>1</manvolnum>
</citerefentry>.
</para>
</section>

</section>

<section id="tools-porting">
<title>Porting tools</title>
<para>
The following tools are helpful for porters and for cross-compilation.
</para>
<section id="quinn-diff">
<title><systemitem role="package">quinn-diff</systemitem></title>
<para>
<systemitem role="package">quinn-diff</systemitem> is used to locate the
differences from one architecture to another.  For instance, it could tell you
which packages need to be ported for architecture <replaceable>Y</replaceable>,
based on architecture <replaceable>X</replaceable>.
</para>
</section>

<section id="dpkg-cross">
<title><systemitem role="package">dpkg-cross</systemitem></title>
<para>
<systemitem role="package">dpkg-cross</systemitem> is a tool for installing
libraries and headers for cross-compiling in a way similar to <systemitem
role="package">dpkg</systemitem>.  Furthermore, the functionality of
<command>dpkg-buildpackage</command> and <command>dpkg-shlibdeps</command> is
enhanced to support cross-compiling.
</para>
</section>

</section>

<section id="tools-doc">
<title>Documentation and information</title>
<para>
The following packages provide information for maintainers or help with
building documentation.
</para>
<section id="debiandoc-sgml">
<title><systemitem role="package">debiandoc-sgml</systemitem></title>
<para>
<systemitem role="package">debiandoc-sgml</systemitem> provides the DebianDoc
SGML DTD, which is commonly used for Debian documentation.  This manual, for
instance, is written in DebianDoc.  It also provides scripts for building and
styling the source to various output formats.
</para>
<para>
Documentation for the DTD can be found in the <systemitem
role="package">debiandoc-sgml-doc</systemitem> package.
</para>
</section>
<!-- TODO: Maybe better:
<section id="docbook-xml">
<title><systemitem role="package">docbook-xml</systemitem></title>
<para>
<systemitem role="package">docbook-xml</systemitem> provides the
DocBook XML DTDs, which are commonly used for Debian documentation (as
is the older debiandoc SGML DTD). This manual, for instance, is written
in DocBook XML. The <systemitem
role="package">docbook-xsl</systemitem> package provides the XSL files
for building and styling the source to various output formats. You
will need an XSLT processor, such as <systemitem
role="package">xsltproc</systemitem>, and an FO processor, such as
<systemitem role="package">fop</systemitem>, to generate documentation.
</para>
</section>
-->

<section id="debian-keyring">
<title><systemitem role="package">debian-keyring</systemitem></title>
<para>
Contains the public GPG and PGP keys of Debian developers.  See <xref
linkend="key-maint"/> and the package documentation for more information.
</para>
</section>

<section id="debview">
<title><systemitem role="package">debview</systemitem></title>
<para>
<systemitem role="package">debview</systemitem> provides an Emacs mode for
viewing Debian binary packages.  This lets you examine a package without
unpacking it.
</para>
</section>

</section>
<!-- FIXME: add the following

questionable:
  dbs (referred to above)
  dpatch (referred to above)
  debarchiver
  ucf
  dpkg-awk
  grep-dctrl
  d-shlibs
  wajig
  magpie
  apt-dpkg-ref
  apt-show-source
  apt-show-versions
  pdbv
  epm
  apt-src
  apt-build

rejected:
  debaux: too new, unmaintained?
  dh-make-perl: too new, unmaintained?
-->
</appendix>