Table des matières
Cette section contient un aperçu rapide des outils dont dispose leresponsable. Cette liste n'est ni complète, ni définitive, il s'agitjuste d'un guide des outils les plus utilisés.
Les outils du responsable Debian sont destinés à aider les responsableset libérer leur temps pour des tâches plus cruciales. Comme le dit LarryWall, il y a plus d'une manière de le faire.
Certaines personnes préfèrent utiliser des outils de haut niveau,d'autres pas. Debian n'a pas de position officielle sur laquestion ; tout outil conviendra du moment qu'il fait leboulot. C'est pourquoi cette section n'a pas été conçue pour indiquer àchacun quel outil il doit utiliser ou comment il devrait faire pourgérer sa charge de responsable Debian. Elle n'est pas non plus destinéeà favoriser l'utilisation d'un outil aux dépens d'un autre.
La plupart des descriptions de ces outils proviennent des descriptionsde
leurs paquets. Vous trouverez plus d'informations dans lesdocumentations de
ces paquets. Vous pouvez aussi obtenir plusd'informations avec la commande
apt-cache show<nom_paquet>
.
Les outils suivants sont pratiquement nécessaires à tout responsable.
dpkg-dev
contains the tools
(including dpkg-source) 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.
debconf
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.
You can find documentation for this package in the debconf-doc
package.
Many feel that this system should be used for all packages which require
interactive configuration; see Section 6.5, « Gestion de la configuration avec debconf
» .
debconf
is not currently required by
Debian Policy, but that may change in the future.
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.
lintian
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.
You should periodically get the newest lintian
from unstable
and
check over all your packages. Notice that the -i
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.
Refer to Section 5.3, « Testing the package » for more information on how and when to use Lintian.
You can also see a summary of all problems reported by Lintian on your
packages at http://lintian.debian.org/. These reports contain the
latest lintian output for the whole development
distribution (unstable
).
debdiff (from the devscripts
package, Section A.6.1, « 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.
You can run it over a pair of binary packages:
debdiff package_1-1_arch.deb package_2-1_arch.deb
Or even a pair of changes files:
debdiff package_1-1_arch.changes package_2-1_arch.changes
For more information please see debdiff(1).
Package building tools make the process of writing
debian/rules
files easier. See Section 6.1.1, « Scripts d'assistance » for more information about why these might or
might not be desired.
debhelper
is a collection of
programs which can be used in debian/rules
to automate
common tasks related to building binary Debian packages. debhelper
includes programs to install various
files into your package, compress files, fix file permissions, and integrate
your package with the Debian menu system.
Unlike some approaches, debhelper
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.
There are a number of little debhelper
add-on packages, too transient to
document. You can see the list of most of them by doing apt-cache
search ^dh-
.
debmake
, a precursor to debhelper
, is a more coarse-grained
debian/rules
assistant. It includes two main programs:
deb-make, which can be used to help a maintainer convert
a regular (non-Debian) source archive into a Debian source package; and
debstd, which incorporates in one big shot the same sort
of automated functions that one finds in debhelper
.
The consensus is that debmake
is now
deprecated in favor of debhelper
.
It is a bug to use debmake
in new
packages. New packages using debmake
will be rejected from the archive.
The dh-make
package contains
dh_make, a program that creates a skeleton of files
necessary to build a Debian package out of a source tree. As the name
suggests, dh_make is a rewrite of debmake
and its template files use dh_* programs
from debhelper
.
While the rules files generated by dh_make 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.
yada
is another packaging helper
tool. It uses a debian/packages
file to auto-generate
debian/rules
and other necessary files in the
debian/
subdirectory. The
debian/packages
file contains instruction to build
packages and there is no need to create any Makefile
files. There is possibility to use macro engine similar to the one used in
SPECS files from RPM source packages.
For more informations see YADA site
.
The following packages help with the package building process, general driving dpkg-buildpackage as well as handling supporting tasks.
cvs-buildpackage
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.
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 stable
, unstable
and
possibly experimental
distributions, along with the other
benefits of a version control system.
The debootstrap
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.
Having a system like this can be useful in many ways. For instance, you can chroot 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.
pbuilder
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.
A related package is pbuilder-uml
,
which goes even further by doing the build within a User Mode Linux
environment.
sbuild
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 Section 5.10.3.3, « wanna-build
» for more information, and http://buildd.debian.org/ to see the system in action.
The following packages help automate or simplify the process of uploading packages into the official archive.
dupload
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.
The dput
package and script does
much the same thing as dupload
, but
in a different way. It has some features over dupload
, such as the ability to check the GnuPG
signature and checksums before uploading, and the possibility of running
dinstall in dry-run mode after the upload.
The dcut
script (part of the package
Section A.5.2, « dput
» ) helps in removing files from the ftp upload
directory.
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 config.sub
.
devscripts
is a package containing
wrappers and tools which are very helpful for maintaining your Debian
packages. Example scripts include debchange and
dch, which manipulate your
debian/changelog
file from the command-line, and
debuild, which is a wrapper around
dpkg-buildpackage. The bts utility is
also very helpful to update the state of bug reports on the command line.
uscan can be used to watch for new upstream versions of
your packages. debrsign 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.
See the devscripts(1) manual page for a complete list of available scripts.
autotools-dev
contains best
practices for people who maintain packages which use
autoconf and/or automake. Also
contains canonical config.sub
and
config.guess
files which are known to work on all
Debian ports.
dpkg-repack 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 /etc
were
modified), the new package will inherit the changes.
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.
alien converts binary packages between various packaging formats, including Debian, RPM (RedHat), LSB (Linux Standard Base), Solaris, and Slackware packages.
debsums checks installed packages against their MD5 sums. Note that not all packages have MD5 sums, since they aren't required by Policy.
dpkg-dev-el
is an Emacs lisp package
which provides assistance when editing some of the files in the
debian
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 debian/changelog
file.
dpkg-depcheck (from the devscripts
package, Section A.6.1, « devscripts
»
) runs a command under strace to determine all the
packages that were used by the said command.
For Debian packages, this is useful when you have to compose a
Build-Depends
line for your new package: running the
build process through dpkg-depcheck will provide you with
a good first approximation of the build-dependencies. For example:
dpkg-depcheck -b debian/rules build
dpkg-depcheck can also be used to check for run-time dependencies, especially if your package uses exec(2) to run other programs.
For more information please see dpkg-depcheck(1).
The following tools are helpful for porters and for cross-compilation.
quinn-diff
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
Y
, based on architecture
X
.
The following packages provide information for maintainers or help with building documentation.
docbook-xml
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 docbook-xsl
package provides the
XSL files for building and styling the source to various output formats. You
will need an XSLT processor, such as xsltproc
, to use the XSL stylesheets.
Documentation for the stylesheets can be found in the various docbook-xsl-doc-*
packages.
To produce PDF from FO, you need an FO processor, such as xmlroff
or fop
. Another tool to generate PDF from DocBook
XML is dblatex
.
debiandoc-sgml
provides the
DebianDoc SGML DTD, which is commonly used for Debian documentation, but is
now deprecated (docbook-xml
should
be used instead). It also provides scripts for building and styling the
source to various output formats.
Documentation for the DTD can be found in the debiandoc-sgml-doc
package.
Contains the public GPG and PGP keys of Debian developers. See Section 3.2, « Gérer votre clé publique » and the package documentation for more information.
Contains the public GPG keys of Debian Maintainers. See http://wiki.debian.org/Maintainers for more information.