Nachdem die Vorbereitungen an den Dateien im Verzeichnis debian/ abgeschlossen sind, kann mit dem Programm dpkg-buildpackage das Paket erstellt werden.

dpkg-buildpackage wird ohne weitere Parameter versuchen, die Sourcen und die Changes-Datei des Pakets digital zu signieren. Hierzu wird ein vorhandener GnuPG-Key benutzt. Ist kein solcher Key erzeugt worden, so kann das Signieren mit den Optionen -us (unsigned source) und -uc (unsigned changes) verhindert werden. Im einfachsten Fall genügt also das Kommando dpkg-buildpackage -us -uc (als „root“), um das Paket zu erzeugen.

dpkg-buildpackage verfügt natürlich noch über viele weitere Optionen:

debian:~# dpkg-buildpackage -h
Debian dpkg-buildpackage .  
Copyright (C) 1996 Ian Jackson.
Copyright (C) 2000 Wichert Akkerman
This is free software; see the GNU General Public Licence version 2
or later for copying conditions.  There is NO warranty.

Usage: dpkg-buildpackage [options]
Options: -r<gain-root-command>
         -p<sign-command>
	 -d            do not check build dependencies and conflicts
	 -D            check build dependencies and conflicts
	 -k<keyid>     the key to use for signing
         -sgpg         the sign-command is called like GPG
         -spgp         the sign-command is called like PGP 
         -us           unsigned source
         -uc           unsigned changes
         -a<arch>      Debian architecture we build for (implies -d)
         -b            binary-only, do not build source } also passed to
         -B            binary-only, no arch-indep files } dpkg-genchanges
         -S            source only, no binary files     } 
         -t<system>    set GNU system type  } passed to dpkg-architecture
         -v<version>   changes since version <version>      }
         -m<maint>     maintainer for package is <maint>    } 
         -e<maint>     maintainer for release is <maint>    } only passed
         -C<descfile>  changes are described in <descfile>  }  to dpkg-
         -si (default) src includes orig for rev. 0 or 1    } genchanges
         -sa           uploaded src always includes orig    }
         -sd           uploaded src is diff and .dsc only   }
         -nc           do not clean source tree (implies -b)
         -tc           clean source tree when finished
         -ap           add pause before starting signature process
         -h            print this message
         -W            Turn certain errors into warnings.      } passed to
         -E            When -W is turned on, -E turned it off. } dpkg-source
         -i[<regex>]   ignore diffs of files matching regex } only passed to dpkg-source

dpkg-buildpackage benötigt eine Umgebung, die der späteren Installationsumgebung ähnlich ist. Das Paket kann als Superuser (root) erzeugt werden, um dies zu gewährleisten. Nun macht es wenig Sinn, einen GnuPG-Key für den Superuser zu erzeugen. Um dieses Problem zu umgehen, dient die Option -r, unmittelbar gefolgt von einem Kommando, das es dem Benutzer erlaubt, Kommandos als Superuser auszuführen bzw. das eine virtuelle root-Umgebung schafft. Dies kann beispielsweise das Kommando fakeroot oder sudo sein, ggf. ist natürlich die Konfiguration des Programms (sudo) für diesen Benutzer anzupassen.

Viele der weiteren Optionen können und sollten in den Konfigurationsdateien im Verzeichnis debian/ definiert werden; bei Bedarf können diese aber auch auf der Kommandozeile angepasst werden.

cvs-buildpackage unterstützt das Erzeugen von Debian Paketen, bei denen die Sourcen des Pakets mit CVS verwaltet werden. cvs-buildpackage ist ein Skript, das dpkg-buildpackage nutzt. Dabei wird zunächst die Datei debian/changelog interpretiert und die aktuelle Paketversion exportiert. Es wird überprüft, ob alle Änderungen bereits in den CVS-Baum importiert wurden, sollte dies nicht der Fall sein, so wird der Vorgang abgebrochen und dem Benutzer wird die Möglichkeit gegeben, die veränderten Dateien in das CVS zu importieren.

Beachten Sie, dass das Arbeitsverzeichnis, aus dem heraus cvs-buildpackage aufgerufen wird, die spätere Entwicklungsumgebung enthält. In diesem Verzeichnis werden die aus dem CVS exportierten Dateien gespeichert, und cvd-buildpackage hat die volle Kontrolle über dieses Verzeichnis. Das bedeutet, dass alle Dateien, mit Ausnahme der originalen Sourcen, gelöscht werden können. Stellen Sie sicher, dass Sie nicht in Ihrem aktuellen Entwicklungszweig mit diesem Programm arbeiten; es können alle Daten verloren gehen!

Zusammen mit den Programmen cvs-inject und cvs-upgrade bildet dieses Programm die Infrastruktur, die es Debian Entwicklern erlaubt, CVS als zentrales Entwicklungswerkzeug einzusetzen. Hierbei wird insbesondere die Verwendung verschiedener Release-Stände eines Pakets, also beispielsweise „stable“, „unstable“ oder auch „Experimental“, unterstützt.

Alle weiteren Kommandozeilenargumente werden nicht interpretiert und vollständig an das Programm dpkg-buildpackage durchgereicht.

Neben den Kommandozeilenoptionen versucht cvs-buildpackage zunächst in der Datei /etc/cvsdeb.conf, systemweite Einstellungen zu finden. Danach wird, wenn vorhanden, eine benutzerbezogene Datei ~/.cvsdeb.conf gelesen und interpretiert.

cvs-autoreleasedeb erlaubt die Übertragung von Paketen auf einen Server, welche von cvs-buildpackage aus einem CVS-Modul erzeugt wurden. CVS

cvs-autoreleasedeb verwaltet Informationen zu allen Paketen, die automatisch auf einen Server übertragen werden sollen. Wird die Datei debian/changelog im CVS aktualisiert und die Debian Versionsnummer des Paketes dabei vergrößert, so wird dieses Paket automatisch auf den Server übertragen.

Alle Einstellungen dieses Programmes werden in der Konfigurationsdatei cvs-autoreleasedeb.conf verwaltet. cvs-autoreleasedeb kennt keinerlei Kommandozeilenparameter.

cvs-autoreleasedeb kann auf zwei Arten eingesetzt werden. Zunächst ist es möglich, als Benutzer cvs-autoreleasedeb das Skript über einen Cron-Job aufzurufen. Dies ist sinnvoll, wenn regelmäßig neue Versionen der Pakete (beispielsweise im Rahmen eines Software-Entwicklungsprojektes) zur Verfügung gestellt werden sollen. In diesem Fall wird die Konfigurationsdatei /etc/cvs-autoreleasedeb.conf gelesen und ausgewertet, die Pakete werden im Verzeichnis /var/lib/cvs-autoreleasedeb/ erzeugt. Sollcvs-autoreleasedeb auf diese Weise genutzt werden, so ist die Datei /etc/default/cvs-autoreleasedeb anzupassen. Die Ausgabe des Programmes cvs-autoreleasedeb wird in die Datei /var/log/cvs-autoreleasedeb/run.log geschrieben.

Alternativ kann cvs-autoreleasedeb durch den Benutzer direkt aufgerufen werden. In diesem Fall wird als Konfigurationsdatei die Datei $HOME/.cvs-autoreleasedeb/conf eingesetzt. Die erzeugten Pakete landen im Verzeichnis $HOME/.cvs-autoreleasedeb/. cvs-autoreleasedeb setzt hierbei keine Vorgabewerte ein, es muss also zwingend eine sinnvolle Konfigurationsdatei vorhanden sein.

Mit debchange kann die Datei debian/changelog in einem Debian Source-Verzeichnisbaum verwaltet werden. Vereinfacht kann auch der Alias dch verwendet werden. Das Kommando debchange muss immer innerhalb des Verzeichnisses aufgerufen werden, in dem sich die Sourcen zu dem zu erstellenden Debian Paket befinden. Es wird ein Texteditor gestartet und automatisch ein neuer Eintrag dem changelog hinzugefügt. (Es werden die Umgebungsvariablen VISUAL und EDITOR benutzt, um den gewünschten Editor zu bestimmen.) Wird der gewünschte Text bereits auf der Kommandozeile angegeben, so kann debchange auch in einem Skript ohne weitere Interaktion des Benutzers ablaufen. Der Eintrag wird an der entsprechenden Stelle hinzugefügt, inklusive aller notwendigen Umbrüche.

Die Syntax für dieses Kommando lautet:

debchange [options] [text ...]
dch [options] [text ...]

Wird der Editor ohne Änderungen an der Datei verlassen, so wird auch von debchange keine weitere Änderung an der Datei vorgenommen. Wenn ein Editor benutzt wird, der mit der Option +n an eine bestimmte Stelle in einem Dokument springen kann, so wird die Schreibmarke direkt an die passende Stelle in der changelog-Datei gesetzt.

Beachten Sie, dass changelog-Dateien immer mit einer UTF-8-Kodierung gespeichert werden. Sollte dies nicht der Fall sein, so können Sie das Programm iconv verwenden, um die Datei umzuwandeln.

debchange kann darüber hinaus mit der Option --closes Einträge erzeugen, die dazu führen, dass ein Bug im Debian Bug Tracking System geschlossen wird. Hierzu wird das Debian BTS (Debian Bug Tracking System, bugs.debian.org/) nach dem Titel und dem Paketnamen durchsucht. Mit der Option --noquery oder der Umgebungsvariablen DEBCHANGE_QUERY_BTS, die auf den Wert no gesetzt sein muss, kann diese Abfrage verhindert werden.

Meistens wird eine der Optionen --append, --increment oder --newversion, wie weiter unten beschrieben, eingesetzt. Werden keine Optionen angegeben, so versucht debchange eine Logdatei von dupload oder dput im darüberliegenden Verzeichnis zu finden, um zu ermitteln, ob die bestehende Version eines Paketes bereits erfolgreich auf einen Server übertragen wurde. Die Ausgabe einer Warnung erfolgt, falls eine Logdatei gefunden wurde, in dieser jedoch kein erfolgreicher Upload verzeichnet ist.

Werden die Optionen --increment und --newversion benutzt, so wird der Name und die E-Mail- Adresse für die neue Version wie folgt ermittelt. Ist die Umgebungsvariable DEBFULLNAME gesetzt, so wird der Inhalt als Name des Maintainers (Paketbetreuer) verwendet. Weiterhin wird die Umgebungsvariable DEBEMAIL ausgewertet. Ist diese gesetzt, so wird der Inhalt als Mail-Adresse verwendet. Hat diese Variable einen Wert, der der Syntax name <email> entspricht, so wird auch der Name aus dieser Variablen verwendet, falls DEBFULLNAME nicht gesetzt ist.

Ist die Variable DEBEMAIL nicht gesetzt, so wird versucht, die Information aus der Variablen EMAIL zu ermitteln. Konnte der Name bisher nicht ermittelt werden, so wird der Systemaufruf getpwuid(3) verwendet, um den Namen aus der Datei /etc/passwd zu ermitteln. Schlägt auch dies fehl, so wird der letzte Eintrag in der changelog-Datei ausgewertet.

Konnte die E-Mail-Adresse nicht ermittelt werden, so wird versucht, diese aus der Datei /etc/mailname zu ermitteln. Danach wird der Benutzername zusammen mit dem FQDN getestet. Gibt auch dies keinen sinnvollen Wert, so wird auch hier die Datei changelog ausgewertet. Abschließend ist festzuhalten, dass die Variablen DEBFULLNAME und DEBEMAIL gesetzt werden sollten, wenn dieses Skript eingesetzt wird.

Besteht der Verzeichnisname, der den Quellcode enthält, aus dem Paketnamen und der Versionsnummer, so versucht debchange dieses Verzeichnis umzubenennen, falls die Upstream-Versionsnummer verändert wurde. Dies kann mit der Option --preserve auf der Kommandozeile oder auch in der Konfigurationsdatei verhindert werden, wie weiter unten beschrieben.

debchange versucht beim Start, die Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts in dieser Reihenfolge einzulesen. Werte in den Konfigurationsdateien können durch Optionen auf der Kommandozeile überschrieben werden. Folgende Variablen werden in den Konfigurationsdateien unterstützt:

Weiterhin werden von debchange die Umgebungsvariablen DEBEMAIL, EMAIL und DEBFULLNAME ausgewertet. Mit der Umgebungsvariable VISUAL oder EDITOR kann auch der bevorzugte Texteditor bestimmt werden.

debdiff vergleicht die Dateien in zwei einzelnen oder auch in Gruppen von Debian Paketen. Die Syntax für dieses Kommando lautet:

debdiff [options] ... deb1 deb2
debdiff [options] ... changes1 changes2
debdiff [options] ... --from deb1a deb1b ...  --to deb2a deb2b ...
debdiff [options] ... dsc1 dsc2

Beim Vergleich der Debian Pakete werden alle Dateien verglichen, die direkt zum Paket gehören, also nicht die Hilfsskripte, die vor oder nach der Installation der Dateien aufgerufen werden. Angezeigt werden dabei alle neu hinzugekommenen oder aus dem Paket entfernten Dateien zwischen den beiden Versionen des Pakets. Weiterhin wird mit dem Programm wdiff ein Vergleich der control-Dateien in den Paketen vorgenommen und das Ergebnis angezeigt.

Es können mit debdiff auch Gruppen von Paketen verglichen werden, debdiff unterstützt dies auf zwei Arten: Zunächst können zwei .changes-Dateien angegeben werden. Die in diesen Dateien aufgeführten Debian Pakete werden daraufhin verglichen, indem der Inhalt aller Pakete zusammengeführt wird. Hierzu müssen sich die Debian Pakete im Verzeichnis der .changes-Datei befinden.

Alternativ können die gewünschten Debian Pakete auf der Kommandozeile mittels der Optionen --from und --to angegeben werden. Hiermit kann festgestellt werden, ob bei einem Aufsplitten des Pakets Dateien verloren gegangen sind. control-Dateien werden in beiden Fällen nur beachtet, wenn lediglich zwei Debian Pakete miteinander verglichen werden.

debdiff verwendet die Konfigurationsdateien aus dem Paket devscripts. Die Einstellungen in den Konfigurationsdateien können dabei immer mit den Kommandozeilenoptionen überschrieben werden.

Werden debdiff zwei Quellcode-Pakete (.dsc-Dateien) beim Aufruf übergeben, so werden die Inhalte dieser Quellcode-Pakete verglichen. Unterscheiden sich die beiden Pakete nur in der Debian Versionsnummer (die Dateien .orig.tar.gz und .dsc sind gleich), dann wird das Programm interdiff benutzt, um die „Patches“ zu vergleichen. Ist dieses Programm nicht vorhanden, so wird diff verwendet, um die beiden Quellcode-Bäume miteinander zu vergleichen.

debdiff benutzt die Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts. Alle in diesen Konfigurationsdateien verwendeten Optionen können auf der Kommandozeile überschrieben werden. debdiff benutzt die folgenden Variablen in den Konfigurationsdateien:

dpkg-depcheck ermittelt die Abhängigkeiten eines Programms. Hierbei wird das Programm mittels strace gestartet und die verwendeten Programme ermittelt. Die ausgegebene Liste kann mit verschiedenen Optionen den Bedürfnissen angepasst werden.

Zur Veranschaulichung hier ein Beispiel:

fr@wasabi:~$ dpkg-depcheck -ab gpg --list-key 887EB817 
gpg: Hinweis: Alte voreingestellte Optionendatei '/home/fr/.gnupg/options'
wurde ignoriert
gpg: WARNUNG: Sensible Daten könnten auf Platte ausgelagert werden.
gpg: siehe http://www.gnupg.org/faq.html für weitere Informationen
pub  1024D/887EB817 2000-12-12 Frank Ronneburg <fr@tischbahn.de>
uid                            Frank Ronneburg <fr@debiananwenderhandbuch.de>
sub  1024g/B91B2CCC 2000-12-12



----------------------------------------------------------------------
The following files did not appear to belong to any package:
/usr/lib/locale/locale-archive
Packages needed:
  locales
  gnupg
  libbz2-1.0

(Build-)Essential packages used:
  zlib1g
  libc6

Zunächst wird die Ausgabe des Programms, hier gpg --list-key 887EB817, ausgegeben. Danach folgen die Auswertungen von dpkg-depcheck. Die Optionen -ab zeigen die Abhängigkeiten zur Laufzeit (-a) und zur Erzeugung (-b) des Pakets an.

Die Syntax von dpkg-depcheck lautet:

dpkg-depcheck [options] command

dpkg-debcheck nutzt die beiden Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts. Über die beschriebenen Kommandozeilenoptionen können die Werte in den Konfigurationsdateien überschrieben werden. Alternativ können hierzu auch Umgebungsvariablen genutzt werden.

dpkg-debcheck nutzt momentan nur die Umgebungsvariable DPKG_DEPCHECK_OPTIONS. Die hier angegebenen Optionen werden vor den Optionen auf der Kommandozeile ausgewertet. Hier ein Beispiel:

DPKG_DEPCHECK_OPTIONS="-b -f-catch-alternatives"

Mit dscverify können die PGP- oder GnuPG-Signaturen von .changes- oder .dsc-Dateien mit den Schlüsseln aus dem Debian Schlüsselbund (aus dem Paket debian-keyring) überprüft werden. Mit einer Option können auch andere Schlüsselbunde angegeben werden. Es werden alle angegebenen Dateien in den .changes- und .dsc-Dateien überprüft. Werden keine Abweichungen festgestellt, so ist der Rückgabewert 0.

Als einzige Konfigurationsvariable wird momentan DSCVERIFY_KEYRINGS unterstützt. Dies ist eine kommaseparierte Liste von Schlüsselbunden, die zur Überprüfung herangezogen werden sollen. Zusätzlich auf der Kommandozeile angegebene Schlüsselbunde werden ebenfalls berücksichtigt.

Es werden weiterhin die Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts ausgewertet. Diese werden ignoriert, wenn die Option --no-conf oder --noconf angegeben wird.

Dieses Programm holt die Datei update_excuses.html aus dem Netz und durchsucht diese nach einem angegebenen Maintainer (Betreuer eines Debian Paketes). Diese Datei enthält, für die jeweils aktuelle „testing“-Distribution, „Ausreden“ der Betreuer, warum ein Paket nicht aktuell oder in einem schlechten Zustand ist.

Die Syntax von grep-excuses lautet

grep-excuses [options] [maintainer|package]

Wird beim Aufruf des Programmes kein Name eines Paketbetreuers angegeben, so wird versucht, den Namen aus der Umgebungsvariablen DEBFULLNAME zu lesen. Schlägt auch dies fehl, so wird der Name aus den Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts aus dem Wert GREP_EXCUSES_MAINTAINER ermittelt.

Alternativ kann zum Namen des Betreuers auch ein Paketname auf der Kommandozeile angegeben werden.

plotchangelog stellt Änderungen an einem Debian Paket anhand der Informationen aus der Datei changelog grafisch dar. Die Syntax von plotchangelog lautet

plotchangelog [options] changelog ...

plotchangelog nutzt das Programm gnuplot für die grafische Darstellung. Die X-Achse stellt dabei den Zeitpunkt des Release einer Version dar, die Y-Achse repräsentiert die Versionsnummer selbst. Jedes einzelne Release wird dabei durch einen Punkt auf der Zeitachse dargestellt, betreuen unterschiedliche Maintainer ein Paket, so wird für jeden Maintainer dieses Paketes eine gesonderte Linie mit Punkten in unterschiedlichen Farben gezeichnet.

Alternativ kann auf der Y-Achse die Größe jedes Eintrages in der Datei changelog oder die Anzahl der beseitigten Fehler je Version des Paketes dargestellt werden.

debclean be-„reinigt“ einen Quellcode-Verzeichnnisbaum. debclean durchsucht ab dem Verzeichnis, aus dem heraus es aufgerufen wurde, alle Unterverzeichnisse und führt das Kommando debian/rules clean für jedes gefundene Debian Quellcode-Verzeichnis aus. Die entsprechenden Verzeichnisse werden anhand einer vorhandenen Datei debian/changelog gefunden, in der der Paketname dem Verzeichnisnamen entspricht. Dieser Vergleich wird später noch genauer erläutert.

Der Aufruf von debclean erfolgt anhand der Syntax

debclean [options]
	

Wird die Option --cleandebs verwendet, so werden die Dateien mit der Endung *.deb, *.changes und *.build in allen Verzeichnissen entfernt. Die Dateien .dsc, .diff.gz und (.orig).tar.gz werden nicht verändert, so dass die aktuelle Version eines Paketes in jedem Fall wiederhergestellt werden kann. Weiterhin wird die Datei .upload nicht verändert, damit debchange korrekt funktioniert.

Die Option --nocleandebs verhindert das zuvor beschriebene Verhalten. Voreingestellt ist, dass keine Dateien gelöscht werden. debclean nutzt das Kommando debuild zum Bereinigen des Verzeichnisbaumes.

debi installiert die aktuelle Version eines Debian Pakets. Die Syntax für den Aufruf lautet:

debi [options] [changes file] [package ...]

debi ermittelt die aktuelle Version eines Debian Pakets und installiert dieses. Wird eine .changes-Datei auf der Kommandozeile angegeben, so wird versucht, den Paketnamen aus diesem Dateinamen zu ermitteln. Ist dies nicht der Fall, so muss debi innerhalb des Source-Code-Verzeichnisses aufgerufen werden. In diesem Fall versucht debi, eine .changes-Datei in dem Verzeichnis zu finden, das der aktuellen Paketversion entspricht (die notwendigen Angaben werden aus der .changes-Datei übernommen).

Danach wird debpkg -i für jedes in der .changes-Datei aufgeführte Paket ausgeführt. Dabei wird davon ausgegangen, dass alle Pakete im gleichen Verzeichnis liegen wie die Datei .changes.

Werden auf der Kommandozeile eine Anzahl von Paketen übergeben, so wird versucht, ausschließlich diese Pakete zu installieren.

debsign erzeugt eine digitale Signatur mittels GPG/PGP für die Dateien .changes und .dsc eines Debian Paketes. Die Syntax dieses Kommandos lautet

debsign [options] [changes-file|dsc-file]

debsign verhält sich beim Signieren von Paketen wie dpkg-buildpackage, es wird eine unsignierte .dsc- oder .changes-Datei verwendet und digital signiert. Die Größe und die MD5-Checksumme der .dsc-Datei werden dabei neu berechnet und in der Datei .changes durch die neuen Werte ersetzt.

Wird eine .changes- oder .dsc-Datei angegeben, so wird diese signiert. Ist keine Datei angegeben, so wird die Datei debian/changelog ausgewertet, und es wird versucht, den Namen der .changes-Datei im darüber liegenden Verzeichnis zu ermitteln.

Dieses Programm wird eingesetzt, wenn ein Entwickler ein Paket auf einem System erzeugt, auf dem es nicht auf sicherem Wege signiert werden kann. Um das Paket auf einem sicheren System zu signieren, müssen lediglich die (kleinen) Dateien .dsc und .changes übertragen, signiert und wieder auf das ursprüngliche System transferiert werden. Dieser Prozess kann weitgehend automatisiert ablaufen, mit der Option -r werden die Dateien auf das lokale (sichere) System kopiert und nach dem Signieren wieder auf das ursprüngliche System transferiert. Liegen die Dateien alle auf dem lokalen System, so können diese mittels debrsign auf ein anderes System kopiert und dort signiert werden.

Auch debsign nutzt die Einträge in den Konfigurationsdateien des Paketes devscripts.

Es werden die beiden Konfigurationsdateien /etc/devscripts.conf und ~/.devscripts in dieser Reihenfolge ausgewertet. Kommandozeilenoptionen überschreiben Werte in den Konfigurationsdateien. Eventuell gesetzte Umgebungsvariablen gleichen Namens werden ignoriert. Die folgenden Variablen können verwendet werden:

dpatch dient zur Verwaltung von Patches für Quellcode-Pakete. Damit bietet sich die Möglichkeit, Patches aus einem anderen Release einzubinden oder auch die bestehenden Patches zu organisieren. Dies Syntax von dpatch lautet:

dpatch [options] command [command-arguments]

dpatch ermöglicht es, Patches oder Templates im Verzeichnis debian/patches/ ohne weitere Organisation im Quellcode-Baum abzulegen. Um diese Patches während der Übersetzung eines Paketes einzubinden, muss lediglich ein kurzer Eintrag im Makefile des Paketes aufgenommen werden und im Abschnitt patch/unpatch bzw. im Abschnitt clean der Datei debian/rules aufgenommen werden. Für den individuellen Einsatz kann auch /usr/bin/dpatch direkt aufgerufen werden.

dpatch kennt einige globale Optionen, welche das gesamte Verhalten von dpatch verändern. Diese sind:

debc zeigt den Inhalt und weitere Informationen zum aktuellsten Debian Paket. debc muss innerhalb des Quellcode-Verzeichnisses aufgerufen werden, aus dem die Debian Pakete für ein Software-Projekt erzeugt werden. debc ermittelt die neueste Version des Pakets und zeigt den Inhalt und Informationen über die Abhängigkeiten an. Hier ein Beispiel:

fr@wasabi:~/Daten/debian-pakete/modellbahn/pythontrain/pythontrain-1.0$ ls ../
backup                          pythontrain_1.0-1_i386.deb      pythontrain_1.0-3_i386.deb      
pythonTrain.gladep              messages.pot                    pythontrain_1.0-1.tar.gz        
pythontrain_1.0-3.tar.gz        pythonTrain.gladep.bak          pixmaps                         
pythontrain_1.0-2.dsc           pythontrain_1.1-1.dsc           pythonTrain-lang.c
project1                        pythontrain_1.0-2_i386.changes  pythontrain_1.1-1_i386.changes  
pythonTrain.png                 pythontrain-1.0                 pythontrain_1.0-2_i386.deb      
pythontrain_1.1-1_i386.deb      pythonTrain.py                  pythontrain_1.0-1.diff.gz       
pythontrain_1.0-2.tar.gz        pythontrain_1.1-1.tar.gz        pythonTrain.xml  
pythontrain_1.0-1.dsc           pythontrain_1.0-3.dsc           pythonTrain.glade
pythontrain_1.0-1_i386.changes  pythontrain_1.0-3_i386.changes  pythonTrain.glade.bak
fr@wasabi:~/Daten/debian-pakete/modellbahn/pythontrain/pythontrain-1.0$ debc
pythontrain_1.1-1_i386.deb
--------------------------
 neues Debian-Paket, Version 2.0.
 Größe 174430 Byte: control-Archiv= 1276 Byte.
     504 Bytes,    10 Zeilen      control              
    1181 Bytes,    16 Zeilen      md5sums              
     561 Bytes,    15 Zeilen   *  postinst             #!/bin/sh
     160 Bytes,     5 Zeilen   *  postrm               #!/bin/sh
     413 Bytes,    14 Zeilen   *  prerm                #!/bin/sh
 Package: pythontrain
 Version: 1.1-1
 Section: misc
 Priority: optional
 Architecture: i386
 Depends: python2.2, python-glade, python-gtk, python2.2-gtk2, python2.2-glade2, 
          rcsh, glade-common-2, glade-2, gettext, localeconf, localepurge, python2.2-xmlbase, 
          sysutils, python2.2-optik, python2.2-optik
 Installed-Size: 300
 Maintainer: Frank Ronneburg <fr@debiananwenderhandbuch.de>
 Description: Python/GTK Anwendung zur Steuerung von Modellbahnen
  Benötigt wird weiterhin ein SRCP kompatibler Server lokal oder im Netzwerk.
drwxr-xr-x root/root         0 2003-07-15 01:41:35 ./
drwxr-xr-x root/root         0 2003-07-15 01:41:29 ./usr/
drwxr-xr-x root/root         0 2003-07-15 01:41:24 ./usr/bin/
-rwxr-xr-x root/root     20738 2003-07-15 01:41:24 ./usr/bin/pythonTrain
drwxr-xr-x root/root         0 2003-07-15 01:41:27 ./usr/share/
drwxr-xr-x root/root         0 2003-07-15 01:41:24 ./usr/share/doc/
drwxr-xr-x root/root         0 2003-07-15 01:41:33 ./usr/share/doc/pythontrain/
drwxr-xr-x root/root         0 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/
-rw-r--r-- root/root      3181 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/bensoftw.html
-rw-r--r-- root/root      2300 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/index.html
-rw-r--r-- root/root      6094 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/ptrain.html
-rw-r--r-- root/root      3139 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/pythontrain.html
-rw-r--r-- root/root     19486 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/pythonTrain-main.jpg
-rw-r--r-- root/root     24026 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/html/tamsprg.jpg
-rw-r--r-- root/root       389 2003-06-27 11:47:02 ./usr/share/doc/pythontrain/copyright
-rw-r--r-- root/root      2659 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/pythontrain.txt.gz
-rw-r--r-- root/root     54774 2003-07-15 01:41:24 ./usr/share/doc/pythontrain/pythontrain.pdf.gz
-rw-r--r-- root/root       410 2003-07-15 01:36:36 ./usr/share/doc/pythontrain/changelog.Debian.gz
drwxr-xr-x root/root         0 2003-07-15 01:41:24 ./usr/share/pythonTrain/
-rw-r--r-- root/root      4173 2003-07-15 01:41:24 ./usr/share/pythonTrain/pythonTrain.xml
-rw-r--r-- root/root     56642 2003-07-15 01:41:24 ./usr/share/pythonTrain/pythonTrain.glade
-rw-r--r-- root/root     61113 2003-07-15 01:41:24 ./usr/share/pythonTrain/pythonTrain.png
drwxr-xr-x root/root         0 2003-07-15 01:41:27 ./usr/share/doc-base/
-rw-r--r-- root/root       555 2003-06-27 16:57:23 ./usr/share/doc-base/pythontrain
drwxr-xr-x root/root         0 2003-07-15 01:41:29 ./usr/lib/
drwxr-xr-x root/root         0 2003-07-15 01:41:29 ./usr/lib/menu/
-rw-r--r-- root/root       150 2003-06-27 11:47:04 ./usr/lib/menu/pythontrain

Wie zu sehen ist, sind verschiedene (auch ältere) Versionen des Pakets vorhanden. Es wird das aktuellste Paket ermittelt, und es werden Informationen zu diesem Paket ausgegeben.

checkinstall (asic-linux.com.mx/~izto/checkinstall/) ist ein Werkzeug zum Übersetzen von Quellcode-Paketen, welche make einsetzen, und zum Erzeugen von Debian, aber auch RPM- oder SLP-Paketen aus diesen Quellcode-Archiven. Dies vereinfacht die Verwaltung von Quellcode-Paketen, die auf unterschiedlichen Distributionen eingesetzt werden sollen.

checkinstall übersetzt den Quellcode eines Paketes, in dem zunächst make install (oder ein anderes, auf der Kommandozeile von checkinstall übergebenes Argument) aufgerufen wird. Das Paket wird compiliert, es wird ein Binär-Paket erzeugt, und dieses wird installiert. Das erzeugte Paket kann auf weiteren Systemen installiert werden.

checkinstall ist als Debian Paket seit dem „Sarge“-Release verfügbar und kann mittels apt-get install checkinstall installiert werden. Auf älteren Systemen ist das Paket als „Backport“ verfügbar. Hierzu ist die Zeile

 deb http://www.backports.org/debian/ woody checkinstall

der Datei /etc/apt/sources.list hinzuzufügen.

fr@wasabi:~$ sudo apt-get install checkinstall
Password:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
installwatch
Die folgenden NEUEN Pakete werden installiert:
checkinstall installwatch
0 aktualisiert, 2 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 46,9kB Archive geholt werden.
Nach dem Auspacken werden 229kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] 
Hole:1 ftp://ftp.de.debian.org sarge/main installwatch 0.6.3-1 [12,0kB]
Hole:2 ftp://ftp.de.debian.org sarge/main checkinstall 1.5.3-3 [34,8kB]
Es wurden 46,9kB in 2s geholt (18,7kB/s)
Wähle vormals abgewähltes Paket installwatch.
(Lese Datenbank ... 57608 Dateien und Verzeichnisse sind derzeit installiert.)
Entpacke installwatch (aus .../installwatch_0.6.3-1_i386.deb) ...
Wähle vormals abgewähltes Paket checkinstall.
Entpacke checkinstall (aus .../checkinstall_1.5.3-3_all.deb) ...
Richte installwatch ein (0.6.3-1) ...

Richte checkinstall ein (1.5.3-3) ...
fr@wasabi:~$

checkinstall nutzt das Programm installwatch, welches ebenfalls installiert wird.

Im nächsten Schritt sind, falls nicht schon geschehen, die Archive mit den Quellcode-Dateien in ein eigenes Verzeichnis zu entpacken. Wechseln Sie in dieses Verzeichnis, nun sollte zunächst geprüft werden, ob der Quellcode sich problemlos übersetzen lässt. Dies geschieht mittels ./configure --sysconfdir=/etc (falls ein configure-Skript vorhanden ist) und einem anschließenden Aufruf von make. Läuft alles problemlos durch, so kann checkinstall zum Einsatz kommen.

	./configure
	./configure kennt die Option --help, mit der sich alle weiteren Konfigurationsoptionen anzeigen lassen. Sinnvoll ist häufig auch die Option --bindir=/usr/bin, da viele Programme sonst im Verzeichnis /usr/local/ abgelegt werden.

Üblicherweise würde nun der Aufruf von make install ein Quellcode-Paket installieren. Dies hätte jedoch zur Folge, dass das Paketmanagement auf dem System keinerlei Kenntnis von den installierten Dateien erhalten würde. Deshalb wird nun das Kommando checkinstall -D make install aufgerufen.

Am Beispiel des Quellcodes zu wget soll der Einsatz von checkinstall exemplarisch gezeigt werden.

fr@wasabi:/tmp/wget-1.9.1$ ./configure  --sysconfdir=/etc --bindir=/usr/bin
configuring for GNU Wget 1.9.1 
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking whether make sets $(MAKE)... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for gcc... gcc
...
checking for perl5... no
checking for perl... /usr/bin/perl
checking for pod2man... /usr/bin/pod2man
configure: creating ./
config.status
config.status: creating Makefile
config.status: creating src/Makefile
config.status: creating doc/Makefile
config.status: creating util/Makefile
config.status: creating po/Makefile.in
config.status: creating windows/Makefile
config.status: creating src/config.h
config.status: src/config.h is unchanged
config.status: executing default commands
generating po/POTFILES from ./po/POTFILES.in
creating po/Makefile
fr@wasabi:/tmp/wget-1.9.1$

Nun liegt ein Makefile vor, in dem bereits die Anpassungen der Verzeichnisse für die Debian Distribution vorgenommen wurden. Der Aufruf von make übersetzt den Quellcode in ein ausführbares Programm.

fr@wasabi:/tmp/wget-1.9.1$ make
cd src && make CC='gcc' CPPFLAGS=''DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/etc/wgetrc\"
  -DLOCALEDIR=\"/usr/local/share/locale\"' CFLAGS='-O2 -Wall -Wno-implicit'
  LDFLAGS='' LIBS='' prefix='/usr/local' exec_prefix='/usr/local'
  bindir='/usr/bin' infodir='/usr/local/info' mandir='/usr/local/man'
manext='1'
make[1]: Entering directory `/tmp/wget-1.9.1/src'
gcc -I. -I. -I/opt/include   -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/etc/wgetrc\"
  -DLOCALEDIR=\"/usr/local/share/locale\" -O2 -Wall -Wno-implicit -c cmpt.c
...
make[1]: Leaving directory `/tmp/wget-1.9.1/util'
cd windows && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/etc/rc\"
  -DLOCALEDIR=\"/usr/local/share/locale\"' CFLAGS='-O2 -Wall -Wno-implicit'
  LIBS='' prefix='/usr/local' exec_prefix='/usr/local' bindir='/usr/bin'
  infodir='/usr/local/info' mandir='/usr/local/man' manext='1'
make[1]: Entering directory `/tmp/wget-1.9.1/windows'
make[1]: Für das Ziel »all« ist nichts zu tun.make[1]: Leaving directory
  `/tmp/wget-1.9.1/windows'
fr@wasabi:/tmp/wget-1.9.1$

Der Aufruf von make muss ohne Fehlermeldungen durchlaufen, ansonsten ist eine Fehlersuche angesagt.

Abschließend kommt checkinstall zum Einsatz

wasabi:/tmp/wget-1.9.1$ checkinstall -D make install

checkinstall 1.5.3, Copyright 2001 Felipe Eduardo Sanchez Diaz Duran
        This software is released under the GNU GPL.


Installing with "make install"...

========================= Installation results ===========================

Copying documentation directory...
cd src && make CC='gcc' CPPFLAGS='' DEFS='-DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\"/etc/wgetrc -DLOCALEDIR=\"/usr/local/share/locale\"'
CFLAGS='-O2 -Wall -Wno-implicit' LDFLAGS='' S='' prefix='/usr/local'
exec_prefix='/usr/local' bindir='/usr/bin' infodir='/usr/local/nfo'
mandir='/usr/local/man' manext='1' install.bin
make[1]: Entering directory `/tmp/wget-1.9.1/src'
../mkinstalldirs /usr/bin
/usr/bin/install -c wget /usr/bin/wget
...
/usr/bin/install -c -m 644 wget.1 /usr/local/man/man1/wget.1
make[1]: Leaving directory `/tmp/wget-1.9.1/doc'

======================== Installation succesful ==========================

Copying files to the temporary directory...OK

Striping ELF binaries and libraries...OK

Compressing man pages...OK

Building file list...OK


This package will be built according to these values:

0 -  Maintainer: [ root@wasabi ]
1 -  Summary: [ ein erstes Paket ]
2 -  Name:    [ wget-1.9.1 ]
3 -  Version: [ 1.9.1 ]
4 -  Release: [ 1 ]
5 -  License: [ GPL ]
6 -  Group:   [ checkinstall ]
7 -  Architecture: [ i386 ]
8 -  Source location: [ wget-1.9.1 ]
9 -  Alternate source location: [  ]

Enter a number to change any of them or press ENTER to continue:

Nach einiger Zeit können Informationen zu dem Paket angegeben werden. checkinstall versucht, Werte wie den Paketnamen und die Versionsnummer aus dem Verzeichnisnamen zu ermitteln. Die vorgeschlagenen Angaben können hier noch verändert werden.

*****************************************
**** Debian package creation selected ***
*****************************************

Building Debian package...OK

Installing Debian package...OK

Erasing temporary files...OK

Writing backup package...OK

Deleting temp dir...OK


**********************************************************************

Done. The new package has been installed and saved to
/tmp/wget-1.9.1/wget-1.9.1_1.9.1-1_i386.deb

You can remove it from your system anytime using:

     dpkg -r wget-1.9.1

**********************************************************************

Abschließend wird das erzeugte Paket installiert.

Lintian (Homepage: lintian.debian.org/) untersucht Debian Pakete auf Fehler, die nicht der Debian Policy für Pakete (www.debian.org/doc/debian-policy/) entsprechen. Darüber hinaus werden die Pakete auch auf einige andere, häufig vorkommende Fehler hin geprüft.

Lintian kann Debian Binär- und Quellcode sowie „udeb“-Pakete (diese werden vom Debian Installer genutzt) untersuchen. Es wird eine Datenbank mit den Ergebnissen gepflegt; diese Datenbank wird „labratory“ genannt. Mit dieser Datenbank können mehrere Überprüfungen eines Pakets beschleunigt werden, da sehr aufwändige Operationen aus der Datenbank gelesen werden können.

lintian wird wie folgt aufgerufen:

lintian [action] [options] [packages] ...

Dabei kann das zu prüfende Paket auf drei verschiedene Arten angegeben werden: mit dem Dateinamen (paketname.deb), als Paketname, oder es kann die .changes-Datei eines Pakets angegeben werden. Wird der Paketname verwendet, so muss die Variable LINTIAN_DIST in der Konfigurationsdatei auf einen sinnvollen Wert gesetzt werden. lintian durchsucht dann den in dieser Variablen festgelegten Pfad nach Binär- oder Quellcode-Paketen, auf die der angegebene Name passt (die Optionen --binary, --udeb, --source können gesetzt werden, falls nur Pakete eines bestimmten Typs gesucht werden sollen).

Wird eine .changes-Datei angegeben, so werden alle in der Datei aufgeführten Dateien geprüft. Dies ist vor dem Upload von Dateien auf einen Server notwendig.

lintian kennt einige Optionen, von denen jeweils nur eine je Programmaufruf auf der Kommandozeile angegeben werden darf. Diese werden als Aktionen bezeichnet.

Der Einsatz von Lintian ist, trotz der vielen möglichen Optionen, recht einfach. Hier ein kleines Beispiel für ein sehr nachlässig gebautes Paket des Autors:

fr@wasabi:~/Daten/debian-pakete/modellbahn/pythontrain$ lintian pythontrain_1.1-1_i386.deb
E: pythontrain: binary-without-manpage pythonTrain
E: pythontrain: python-script-but-no-python-dep ./usr/bin/pythonTrain
W: pythontrain: unquoted-string-in-menu-item /usr/lib/menu/pythontrain needs:2
W: pythontrain: unquoted-string-in-menu-item /usr/lib/menu/pythontrain section:2
E: pythontrain: menu-icon-not-in-xpm-format /usr/share/pixmaps/gnome-diskfree.png
E: pythontrain: debian-changelog-file-uses-obsolete-national-encoding at line 7
E: pythontrain: package-has-a-duplicate-relation depends: python2.2-optik, python2.2-optik

Bei der Ausgabe unterscheidet Lintian zwischen Fehlern (E: Error) und Warnungen (W: Warning). Diese erscheinen in der ersten Spalte. Danach wird der Paketname angezeigt. Dies ist notwendig, wenn mehrere Pakete in einem Durchlauf geprüft werden. Danach folgt eine Infomation zu dem gefundenen Problem mit einer Angabe, welche Datei, Zeile oder welche Abhängigkeit betroffen ist.

Lintian sucht an den folgenden Orten nach Konfigurationsdateien:

Lintian nutzt die folgenden Verzeichnisse:

Das Verzeichnis /usr/share/lintian kann über die Umgebungsvariabe LINTIAN_ROOT überschrieben werden, alternativ kann auch die Option --root verwendet werden.

Je nachdem, ob die Ausführung von Lintian erfolgreich war, wird ein entsprechender Exit-Status zurückgegeben, mögliche Werte hierfür sind: