Kapitel 6. Bau des Pakets

Inhaltsverzeichnis

6.1. Kompletter (Neu-)Bau
6.2. Autobuilder
6.3. Der Befehl debuild
6.4. Das Paket pbuilder
6.5. Der Befehl git-buildpackage und ähnliche
6.6. Schneller Neubau
6.7. Befehlshierarchie

Nun sollten wir soweit sein, das Paket zu bauen.

Um ein Paket ordnungsgemäß komplett (neu) zu bauen, müssen Sie Folgendes installiert haben:

Dann führen Sie den folgenden Befehl im Quellverzeichnis des Programms aus:

$ dpkg-buildpackage -us -uc

Dies wird alles für Sie erledigen, um vollständige Binärpakete und Quellpakete zu erstellen. Im Einzelnen:

  • Aufräumen des Quellverzeichnisbaums (»debian/rules clean«),

  • Bauen des Quellpakets (»dpkg-source -b«),

  • Bauen des Programms (»debian/rules build«),

  • Bauen der Binärpakete (»fakeroot debian/rules binary«),

  • Erstellen der Datei .dsc

  • Erstellen der Datei .changes, mittels dpkg-genchanges

Falls das Ergebnis des Baus den Erwartungen entspricht, signieren Sie die Dateien .dsc und .changes mit Ihrem privaten GPG-Schlüssel mit dem Befehl debsign. Sie müssen Ihre geheime Passphrase zweimal eingeben. [64]

Für nicht native Debian-Pakete, z.B. gentoo, werden Sie die folgenden Dateien im übergeordneten Verzeichnis (~/gentoo) nach dem Paketbau sehen:

  • gentoo_0.9.12.orig.tar.gz

    Dies ist der ursprüngliche Quelltext-Tarball der Originalautoren, lediglich umbenannt, um dem Debian-Standard zu genügen. Beachten Sie, dass diese Umbenennung beim initialen Aufruf von »dh_make -f ../gentoo-0.9.12.tar.gz« erfolgt ist.

  • gentoo_0.9.12-1.dsc

    Dies ist eine Zusammenfassung des Inhalts des Quellcode-Pakets. Diese Datei wird aus Ihrer Datei control erzeugt und für das Entpacken des Quellcodes mittels dpkg-source(1) benötigt.

  • gentoo_0.9.12-1.debian.tar.gz

    Dieser komprimierte Tarball enthält die Dateien aus Ihrem debian-Verzeichnis. Jede einzelne Änderung, die Sie am ursprünglichen Code vorgenommen haben, wird als quilt-Patch in debian/patches gespeichert.

    Wenn jemand Ihr Paket von Grund auf neu bauen will, kann er dafür einfach die drei oben genannten Dateien verwenden. Das Verfahren des Auspackens ist trivial: Kopieren Sie einfach die drei Dateien in ein Verzeichnis und führen Sie »dpkg-source -x gentoo_0.9.12-1.dsc« aus. [65]

  • gentoo_0.9.12-1_i386.deb

    Das ist Ihr fertiges Binärpaket. Sie können es mit dpkg installieren und wieder entfernen wie jedes andere Paket auch.

  • gentoo_0.9.12-1_i386.changes

    Diese Datei beschreibt alle Änderungen in dieser Paket-Revision. Die Verwaltungsprogramme für Debians FTP-Archive benötigen diese Datei zur Installation der Binär- und Quellcodepakete im FTP-Archiv. Sie wird zum Teil aus den Dateien changelog und .dsc erzeugt.

    Wenn Sie weiter an dem Paket arbeiten, wird sich sein Verhalten ändern und neue Funktionen werden hinzugefügt. Leute, die Ihr Paket herunterladen, können sich diese Datei ansehen und feststellen, was sich geändert hat. Die Verwaltungsprogramme für das Debian-Archiv werden den Inhalt dieser Datei auch an die Mailingliste debian-devel-changes@lists.debian.org schicken.

Die Dateien gentoo_0.9.12-1.dsc und gentoo_0.9.12-1_i386.changes müssen unter Verwendung des Befehls debsign mit Ihrem privaten GPG-Schlüssel, der sich im Verzeichnis ~/.gnupg/ befindet, signiert werden, bevor sie zum Debian-FTP-Archiv hochgeladen werden. Die GPG-Signatur stellt unter Verwendung Ihres öffentlichen GPG-Schlüssels den Nachweis bereit, dass diese Dateien tatsächlich von Ihnen sind.

Mit dem folgenden Eintrag in ~/.devscripts kann der Befehl debsign dazu veranlasst werden, mit Ihrer angegeben geheimen Schlüsselkennung zu unterzeichnen (was gut fürs Spoonsern ist):

DEBSIGN_KEYID=Ihre_GPG-Schlüsselkennung

Die langen Zahlenreihen in den Dateien .dsc und .changes sind SHA1/SHA256-Prüfsummen der aufgelisteten Dateien. Jeder, der Ihr Paket herunterlädt, kann die enthaltenen Dateien mit sha1sum(1) oder sha256sum(1) testen. Wenn die Zahlen nicht übereinstimmen, weiß er, die geprüfte Datei ist beschädigt oder manipuliert.

Debian unterstützt viele Portierungen mit dem Autobuilder-Netz, das buildd-Daemons auf vielen verschiedenen Rechnerarchitekturen ausführt. Obwohl Sie dies nicht selbst durchführen müssen, sollte Ihnen bewusst sein, was mit Ihren Paketen passiert. Lassen Sie uns einen kurzen Blick darauf werfen, wie Ihre Pakete vom Autobuilder-Netz für verschiedene Architekturen neu gebaut werden. [66]

Für Pakete mit »Architecture: any« für das Autobuilder-System eine Neuübersetzung durch. Es stellt folgende Installationen sicher:

Dann führt es den folgenden Befehl im Quellverzeichnis aus:

$ dpkg-buildpackage -B

Hiermit wird alles erledigt, um ein architekturabhängiges Binärpaket für eine andere Architektur zu erstellen. Im Einzelnen:

  • Aufräumen des Quellverzeichnisbaums (»debian/rules clean«),

  • Bauen des Programms (»debian/rules build«),

  • Bauen der architekturabhängigen Binärpakete (»fakeroot debian/rules binary-arch«)

  • Unterschreiben der .dsc-Quelldatei mit gpg,

  • Erstellen und Unterschreiben der für das Hochladen notwendigen .changes-Datei mit dpkg-genchanges und gpg.

Das ist der Grund, weshalb Sie Ihr Paket auch für andere Architekturen sehen.

Obwohl Pakete, die im Feld Build-Depends-Indep aufgeführt sind, installiert sein müssen, wenn wir das Paket bauen (siehe Abschnitt 6.1, „Kompletter (Neu-)Bau“), müssen diese auf dem Autobuilder-System nicht installiert sein, weil es nur architekturabhängige Binärpakete baut. [67] Diese Unterscheidung zwischen dem normalen Bau und der Situation bei dem Autobuilder-Ablauf entscheidet darüber, ob Sie solche erforderlichen Pakete im Feld Build-Depends oder Build-Depends-Indep der Datei debian/control auflisten (siehe Abschnitt 4.1, „control).

Sie können den Prozess des Paketbauens rund um die Ausführung des Befehls dpkg-buildpackage weiter mit dem Befehl debuild automatisieren. Siehe debuild(1).

Der Befehl dbuild führt den Befehl lintian aus, um nach dem Bau des Debian-Pakets statische Prüfungen durchzuführen. Der Befehl lintian kann mit dem folgenden Eintrag in der ~/.devscripts angepasst werden:

DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"

Jetzt kann das Säubern des Quellverzeichnisses und Neubauen des Pakets unter Ihrem Benutzerkonto einfach so durchgeführt werden:

$ debuild

Sie können das Quellverzeichnis einfach so säubern:

$ debuild clean

Um die Abhängigkeiten für den Bau in einer sauberen Umgebung (chroot) zu überprüfen, ist das Paket pbuilder sehr gut geeignet. [68] Es stellt sicher, dass das Paket aus den Quellen auf einem Sid-Autobuilder für verschiedene Architekturen gebaut werden kann. Weiterhin wird hierdurch ein schwerwiegender FTBFS-Fehler (»Fails To Build From Source«, kann nicht aus den Quellen gebaut werden) verhindert, der immer als release-kritisch (RC) angesehen wird. [69]

Lassen Sie uns das Paket pbuilder folgendermaßen anpassen:

  • Machen Sie das Verzeichnis /var/cache/pbuilder/result für Ihr Benutzerkonto schreibbar.

  • Erstellen Sie ein Verzeichnis, z.B. /var/cache/pbuilder/hooks, das ebenfalls für den Benutzer schreibbar ist, so dass Hook-Skripts dort abgelegt werden können.

  • Konfigurieren Sie die Datei ~/.pbuilderrc oder /etc/pbuilderrc, so dass sie folgendes enthält:

    AUTO_DEBSIGN=${AUTO_DEBSIGN:-no}
    HOOKDIR=/var/cache/pbuilder/hooks
    

Lassen Sie uns zuerst das lokale pbuilder-chroot-System wie folgt initialisieren:

$ sudo pbuilder create

Falls Sie ein Quellpaket schon komplett fertiggestellt haben, führen Sie die folgenden Befehle in dem Verzeichnis aus, in dem die Dateien foo.orig.tar.gz, foo.debian.tar.gz und foo.dsc liegen, um das lokale pbuilder-chroot-System zu aktualisieren und Binärpakete darin zu bauen.

$ sudo pbuilder --update
$ sudo pbuilder --build foo_Version.dsc

Die neu erstellten Pakete ohne GPG-Signaturen werden unter /var/cache/pbuilder/result/ mit einem nicht-root-Eigentümer abgelegt.

Die GPG-Unterschriften für die Dateien .dsc und .changes können wie folgt erstellt werden:

$ cd /var/cache/pbuilder/result/
$ debsign foo_Version_Arch.changes

Falls Sie bereits ein aktualisiertes Quellverzeichnis haben, ohne dass die dazu passenden Quellpakete erstellt wurden, führen Sie stattdessen die folgenden Befehle in dem Quellverzeichnis aus, in dem das Verzeichnis debian enthalten ist:

$ sudo pbuilder --update
$ pdebuild

Sie können sich in der erstellten chroot-Umgebung anmelden, indem Sie den Befehl »pbuilder --login --save-after-login« verwenden und diese dann so einrichten wie Sie wollen. Diese Umgebung kann gespeichert werden, indem die Shell-Eingabeaufforderung mittels ^D (Steuerung-D) verlassen wird.

Die aktuelle Version des Programms lintian kann in der chroot-Umgebung ausgeführt werden, indem das Hook-Skript /var/cache/pbuilder/hooks/B90lintian wie folgt eingerichtet wird. [70]

#!/bin/sh
set -e
install_packages() {
        apt-get -y --force-yes install "$@"
        }
install_packages lintian
echo "+++ lintian output +++"
su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder
# Verwenden Sie diese Version, falls Lintian beim Bau nicht fehlschlagen soll
#su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder
echo "+++ end of lintian output +++"

Sie müssen Zugriff auf die neueste Sid-Umgebung haben, damit Sie Pakete korrekt für Sid bauen können. Allerdings kann es in Sid immer wieder mal Probleme geben, so dass Sie wahrscheinlich nicht Ihr gesamtes System umstellen wollen. Das Paket pbuilder bietet einen Ausweg für diese Situation.

Es kann vorkommen, dass Sie Ihre Pakete für Stable aktualisieren müssen, nachdem sie veröffentlicht worden sind, beispielsweise über stable-proposed-updates, stable/updates usw. [71] In einem solchen Fall sollten Sie Ihre Pakete zügig aktualisieren, die Ausrede, dass Sie ein Sid-System verwenden, ist nicht akzeptabel. Das Paket pbuilder kann Ihnen dabei helfen, auf nahezu jede Debian-basierte Distribution derselben Architektur zuzugreifen.

Siehe http://www.netfort.gr.jp/~dancer/software/pbuilder.html, pdebuild(1), pbuilderrc(5) und pbuilder(8).

Falls der Autor des ursprünglichen Programms ein Quelltext-Verwaltungsprogramm (VCS) [72] zur Betreuung des Codes einsetzt, sollten Sie darüber nachdenken, dies ebenfalls zu tun. Damit wird das Zusammenführen und Herauspicken von Patches des Originalautors wesentlich einfacher. Es gibt verschiedene Pakete, die spezialisierte Wrapper-Skripte enthalten, die das Bauen eines Debian-Pakets mit dem jeweiligen VCS erleichtern.

  • git-buildpackage: Eine Suite zur Unterstützung von Debian-Paketen in Git-Depots.

  • svn-buildpackage: Hilfsprogramme zur Betreuung von Debian-Paketen mit Subversion.

  • cvs-buildpackage: Eine Sammlung von Skripten für Debian-Pakete in CVS-Quelltextbäumen.

Die Verwendung von git-buildpackage ist bei Debian-Entwicklern recht beliebt, um Debian-Pakete mit dem Git-Server auf alioth.debian.org zu verwalten. [73] Dieses Paket bietet viele Befehle, um Paketierungsaktivitäten zu automatisieren.

  • git-import-dsc(1): Import eines bestehenden Debian-Pakets in ein Git-Depot.

  • git-import-orig(1): Import eines neuen Tars der Originalautoren in ein Git-Depot.

  • git-dch(1): Erstellung des Debian-Changelogs aus Git-Commit-Nachrichten.

  • git-buildpackage(1): Bau von Debian-Paketen aus einem Git-Depot.

  • git-pbuilder(1): Bau von Debian-Paketen aus einem Git-Depot mit pbuilder/cowbuilder.

Diese Befehle verwenden drei Zweige, um die Paktierungsaktivitäten nachzuverfolgen

  • main für den Debian-Paketierungsquellbaum

  • upstream für den Quellbaum der Originalautoren

  • pristine-tar für Tarbälle der Originalautoren, die mit der Option --pristine-tar erstellt wurden.[74]

Sie können git-buildpackage mit ~/.gbp.conf konfigurieren. Lesen Sie gbp.conf(5). [75]

Bei einem großen Paket wollen Sie bestimmt nicht alles nach jeder kleiner Änderung in debian/rules neu kompilieren. Für Testzwecke können Sie folgendermaßen eine .deb-Datei erstellen, ohne alle Schritte durchzumachen[76]:

$ fakeroot debian/rules binary

Oder noch einfacher, falls Sie nur feststellen wollen, ob das Paket gebaut werden kann oder nicht:

$ fakeroot debian/rules build

Wenn Sie mit Ihren Anpassungen fertig sind, vergessen Sie nicht, das Paket gemäß der korrekten Prozedur neu zu bauen. Sie werden .deb-Dateien, die auf diese Weise gebaut wurden, nicht korrekt hochladen können.

Dies ist eine kurze Zusammenfassung, wie die vielen Befehle zum Paketbau in der Befehlshierarchie zusammenpassen. Es gibt viele Wege, das gleiche zu erledigen.

  • debian/rules = Betreuerskript für den Paketbau

  • dpkg-buildpackage = Kern des Paketbauwerkzeuges

  • debuild = dpkg-buildpackage + lintian (unter bereinigten Umgebungsvariablen bauen)

  • pbuilder = Kern des Debian-Chroot-Umgebungswerkzeuges

  • pdebuild = pbuilder + dpkg-buildpackage (in der Chroot bauen)

  • cowbuilder = Ausführung von pbuilder beschleunigen

  • git-pbuilder = die einfach zu benutzende Syntax für pdebuild (von gbp buildpackge verwandt)

  • gbp = Debian-Quellen in einem Git-Depot verwalten

  • gbp buildpackge = pbuilder + dpkg-buildpackage + gbp

Obwohl die Verwendung von abstrakteren Befehlen wie gbp buildpackge und pbuilder eine perfekte Paketbauumgebung sicherstellen, ist es essenziell, zu verstehen, wie die systemnahen Befehle wie debian/rules und dpkg-buildpackage unter ihnen ausgeführt werden.



[64] Dieser GPG-Schlüssel muss von einem Debian-Entwickler unterschrieben worden sein, um mit dem Vertrauensnetz verbunden zu sein, und muss im Debian-Schlüsselring registriert sein. Dies ermöglicht es, dass Ihre hochgeladenen Pakete im Debian-Archiv akzeptiert werden. Lesen Sie Creating a new GPG key und Debian Wiki on Keysigning.

[65] Sie können das Anwenden der quilt-Patches im 3.0 (quilt)-Quellformat am Ende des Auspackens verhindern, indem Sie die Option --skip-patches benutzen. Alternativ können Sie »dquilt pop -a« nach dem normalen Auspacken aufrufen.

[66] Das tatsächliche Autobuilder-System besteht aus einem wesentlich komplizierteren Schema als dem hier dargestellten. Diese Details führen aber hier zu weit.

[67] Im Gegensatz zum pbuilder-Paket erzwingt die chroot-Umgebung im Paket sbuild, die vom Autobuilder-System verwendet wird, keine Verwendung einer Minimalumgebung. Daher können übriggebliebene Pakete installiert sein.

[68] Weil das Paket pbuilder ständig weiterentwickelt wird, sollten Sie die tatsächliche Konfiguration herausfinden, indem Sie die aktuelle offizielle Dokumentation durchlesen.

[69] Lesen Sie http://buildd.debian.org/ für weitere Informationen über das automatische Bauen von Debian-Paketen.

[70] Dies setzt HOOKDIR=/var/cache/pbuilder/hooks voraus. Sie finden viele Beispiele für Hook-Skripte im Verzeichnis /usr/share/doc/pbuilder/examples.

[71] Es gibt für Aktualisierungen Ihrer Stable-Pakete einige Einschränkungen.

[72] Lesen Sie Version control systems für mehr Informationen.

[73] Das Dokument Debian wiki Alioth dokumentiert, wie der Dienst alioth.debian.org verwandt wird.

[74] Die Option --pristine-tar ruft den Befehl pristine-tar auf, der eine exakte Kopie des ursprünglichen Tarballs erneut erstellt und dabei nur eine kleine binäre Deltadatei und den Inhalt des Tarballs verwendet, der typischerweise im Zweig upstream des VCS gehalten wird.

[75] Hier sind einige Quellen im Web für fortgeschrittene Anwender.

[76] Umgebungsvariablen, die normalerweise auf vernünftige Werte gesetzt sind, werden bei dieser Methode nicht eingerichtet. Erstellen Sie niemals echte Pakete, die hochgeladen werden sollen, mit dieser schnellen Methode.