# Pbuilder-Benutzerhandbuch

## Aufruf und Betrieb

### Junichi Uekawa

Diese Dokumentation ist noch in Bearbeitung und möglicherweise unvollständig oder nicht mehr aktuell.

Tabellenverzeichnis

5.1. Verzeichnisstruktur der Test-Suite
8.1. Verzeichnisstruktur außerhalb der Chroot
8.2. Verzeichnisstruktur innerhalb der Chroot

# Kapitel 1. Einführung in Pbuilder

## 1. Ziele von Pbuilder

pbuilder steht für »Personal Builder« und ist ein automatisches System zum Bau von Debian-Paketen für persönliche Entwickler-Arbeitsplatzumgebungen. Ziel von pbuilder ist es, ein einfach einzurichtendes System zum automatischen Bau von Debian-Paketen innerhalb einer Reinraumumgebung zu sein, so dass eine Prüfung, ob ein Paket in den meisten Debian-Installationen gebaut werden kann, möglich ist. Die Reinraumumgebung wird durch den Gebrauch eines Chroot-Images erreicht, so dass nur eine minimale Zahl von Paketen innerhalb der Chroot installiert wird.

Die Distribution Debian besteht aus freier Software, die zusammen mit Quellen weitergegeben wird. Der Quellkode innerhalb Debians Bereich »main« muss innerhalb Debian-»main« gebaut werden, nur mit den explizit angegebenen installierten Build-Abhängigkeiten.

Das vorrangige Ziel von pbuilder unterscheidet sich von anderen automatischen Bausystemen in Debian darin, dass es nicht das Ziel hat, so viele Pakete wie möglich zu bauen. Es versucht nicht abzuschätzen, was ein Paket benötigt und probiert, wenn eine Auswahl zu treffen ist, in den meisten Fällen die schlechtest mögliche Auswahl von allen.

Auf diese Art versucht pbuilder sicherzustellen, dass Pakete, die mit pbuilder getestet wurden, auf den meisten Debian-Installationen ordentlich gebaut werden, was hoffentlich in einer guten umfassenden Erstellbarkeit von Debian aus den Quellen resultiert.

Das Ziel, Debian aus den Quellen erstellbar zu machen, ist einigermaßen vollendet und hat gute Fortschritte gemacht. In früheren Zeiten, als Debian 3.0 aktuell war, gab es viele Probleme beim Bau aus den Quellen. Bei aktuelleren Versionen von Debian ist dies viel besser.

# Kapitel 2. Pbuilder benutzen

Es gibt mehrere einfache Befehle für den Betrieb. Normalerweise werden die Befehle pbuilder create, pbuilder update und pbuilder build benutzt. Sie werden nun nacheinander vorgestellt.

## 1. Einen Basis-Chroot-Tarball erstellen

pbuilder create erstellt einen Basis-Chroot-Tarball (base.tgz). Alle anderen Befehle werden mit dem resultierenden base.tgz arbeiten. Falls das zu erstellende Debian-Release nicht »sid« sein wird (was Vorgabe ist), muss der Kodename der Distribution mit der Befehlszeilenoption `--distribution` angegeben werden.

debootstrap [1] wird benutzt, um die reine Minimalinstallation von Debian zu erstellen. Dann werden Build-essential-Pakete auf der minimalen Installation unter Benutzung von apt-get innerhalb der Chroot installiert.

Für weitere Dokumentationen der Befehlszeilenoptionen lesen Sie die Handbuchseite pbuilder(8). Zur Benutzung wird manche Konfiguration von `/etc/pbuilderrc` für die Spiegel-Site [2] nötig sein und es könnte notwendig sein, den Proxy zu konfigurieren, um Zugriff über HTTP zu erlauben. Einzelheiten finden Sie in der Handbuchseite von pbuilderrc(5).

## 2. Das base.tgz aktualisieren

pbuilder update wird das base.tgz aktualisieren. Es wird die Chroot extrahieren, apt-get update und apt-get dist-upgrade innerhalb der Chroot ausführen und dann das base.tgz (den Tarball) neu erstellen.

Es ist möglich, die Distribution zu wechseln auf die base.tgz an diesem Punkt verweist. Geben Sie `--distribution `sid`` `--override-config` an, um die Distribution auf Sid zu ändern. [3]

Weitere Dokumentationen der Befehlszeilenoptionen finden Sie in der Handbuchseite pbuilder(8).

## 3. Ein Paket unter Benutzung von base.tgz bauen

Um ein Paket innerhalb der Chroot zu bauen, rufen Sie pbuilder build `wasauchimmer.dsc` auf. pbuilder wird das base.tgz in ein temporäres Verzeichnis extrahieren, mit Chroot in das Verzeichnis wechseln, die Build-Abhängigkeiten erfüllen und das Paket bauen. Das gebaute Paket wird in das Verzeichnis verschoben, das mit der Befehlszeilenoption `--buildresult` angegeben wurde.

Die Option `--basetgz` kann benutzt werden, um anzugeben, welche base.tgz benutzt werden soll.

pbuilder wird ein frisches Chroot-Basis-Image aus base.tgz extrahieren (base.tgz wird mit pbuilder create erstellt und mit pbuilder update aktualisiert). Die Chroot wird durch Auswertung von debian/control und Aufruf von apt-get mit Build-Abhängigkeiten bestückt.

Weitere Dokumentationen der Befehlszeilenoptionen finden Sie in der Handbuchseite pbuilder(8)

## 4. Debian-Entwicklern das Tippen erleichtern: Pdebuild

pdebuild ist ein kleines Wrapper-Skript, das die häufigsten aller Aufgaben erledigt. Ein Debian-Entwickler könnte versuchen, debuild auszuführen und ein Paket innerhalb eines Debian-Quellverzeichnisses zu bauen. pdebuild wird eine ähnliche Steuerung erlauben und ermöglichen, dass Pakete innerhalb der Chroot gebaut werden, um zu prüfen, ob der aktuelle Quellbaum erfolgreich innerhalb der Chroot gebaut wird.

pdebuild ruft zum Bau der Quellpakete dpkg-source und dann für das resultierende Quellpaket pbuilder auf. Anders als bei Debuild können die resultierenden Deb-Dateien jedoch im mit `--buildresult` angegebenen Verzeichnis gefunden werden.

Weitere Einzelheiten finden Sie in der Handbuchseite pdebuild(1).

Es gibt einen etwas anderen Betriebsmodus, der in pdebuild seit Version 0.97 verfügbar ist. pdebuild führt debian/rules clean normalerweise außerhalb der Chroot aus; es ist jedoch möglich, dieses Verhalten mit `--use-pdebuild-internal` zu ändern, damit es innerhalb der Chroot läuft. Es wird versuchen, das Arbeitsverzeichnis innerhalb der Chroot einzuhängen und dpkg-buildpackage darin auszuführen. Es hat die folgenden Merkmale und ist noch nicht der Standardbetriebsmodus.

- Erfüllt die Build-Abhängigkeiten innerhalb der Chroot, bevor das Quellpaket erstellt wird (was ein guter Punkt ist, den Standard-pdebuild nicht beherrscht)

- Das Arbeitsverzeichnis wird von innerhalb der Chroot geändert.

- Bauen mit pdebuild garantiert nicht, dass dies mit pbuilder funktioniert.

- Falls das Erstellen des Quellpakets fehlschlägt, ist die Sitzung vergeudet, die die Chroot verwendet (Erstellen einer Chroot nimmt etwas Zeit in Anspruch, was mit Cowdancer verbessert werden sollte).

- Funktioniert nicht auf die gleiche Weise wie gewohnt; zum Beispiel hat `--buildresult` keine Auswirkungen.

- Das Bauen innerhalb der Chroot wird mit dem aktuellen Benutzer außerhalb der Chroot ausgeführt.

## 5. Konfigurationsdateien

Es ist möglich, alle Einstellungen mit Befehlszeilenoptionen anzugeben. Wegen des Eingabekomforts ist es jedoch möglich, eine Konfigurationsdatei zu benutzen.

Wenn pbuilder aufgerufen wird, werden `/etc/pbuilderrc` und `${HOME}/.pbuilderrc` eingelesen. Die möglichen Optionen sind in der Handbuchseite pbuilderrc(5) dokumentiert.

Es ist nützlich, die Option `--configfile` zu benutzen, um eine voreingestellte Konfigurationsdatei zu laden, wenn zwischen Konfigurationsdateien verschiedener Distributionen gewechselt wird.

Bitte beachten Sie, dass `${HOME}/.pbuilderrc` systemweite Einstellungen überschreibt. Als Vorsichtsmaßnahme, wenn Sie über eine Konfiguration verfügen, müssen Sie die Konfiguration so optimieren, dass sie bei einem Upgrade mit neuen Versionen von Pbuilder funktioniert.

## 6. Pakete innerhalb der Chroot bauen ohne Root zu sein

pbuilder benötigt volle Root-Rechte, um Build-Abhängigkeiten zu erfüllen, aber die meisten Pakete benötigen keine Root-Rechte zum Bau oder verweigern sogar die Erstellung, wenn sie als Root gebaut werden. pbuilder kann einen Benutzer erstellen, der nur innerhalb von pbuilder benutzt wird und diese Benutzer-ID beim Bauen verwenden. Wenn Root-Rechte erforderlich sind, wird der Befehl fakeroot verwandt.

Die Konfigurationsoption BUILDUSERID sollte auf einen Wert für eine Benutzer-ID gesetzt werden, die noch nicht auf dem System existiert, so dass es für Pakete, die mit pbuilder erstellt werden, schwieriger wird, die Umgebung außerhalb der Chroot zu beeinflussen. Wenn außerdem die Konfigurationsoption BUILDUSERNAME gesetzt ist, wird pbuilder den angegebenen Benutzernamen verwenden und zum Bauen von Paketen Fakeroot verwenden, anstatt es als Root innerhalb der Chroot auszuführen.

Sogar wenn die Fakeroot-Methode benutzt wird, wird pbuilder mit Root-Rechten ausgeführt, wenn dies erforderlich ist. Wenn beispielsweise Pakete in die Chroot installiert werden, wird pbuilder mit Root-Rechten ausgeführt.

Um pbuilder aufrufen zu können ohne Root zu sein, müssen Sie User Mode Linux benutzen, wie es unter Kapitel 3, User Mode Linux mit Pbuilder benutzen erklärt wird.

## 7. Pbuilder zur Rückportierung benutzen

pbuilder kann benutzt werden, um Software von der letzten Debian-Distribution auf eine ältere stabile Version zurück zu portieren, indem eine Chroot benutzt wird, die ein Image der älteren Distribution enthält, und die Pakete innerhalb der Chroot erstellt werden. Es sind mehrere Punkte zu beachten und wegen der folgenden Gründe ist automatische Rückportierung normalerweise nicht möglich und manuelle Interaktion erforderlich:

- Das Paket von der Distribution Unstable könnte von Paketen oder Paketversionen abhängig sein, die nur in Unstable verfügbar sind. Daher ist es vielleicht nicht möglich, Build-Abhängigkeiten zu erfüllen: auf Stable (ohne zusätzliche Rückportierungsarbeiten).

- Die Distribution Stable könnte Fehler haben, die in Unstable behoben wurden und an denen gearbeitet werden muss.

- Das Paket in der Distribution Unstable könnte sogar Bauprobleme in Unstable haben.

## 8. Massenhaft Pakete bauen

pbuilder kann automatisiert werden, da seine Operationen nicht interaktiv sind. Es ist möglich, pbuilder für mehrere Pakete ohne Benutzerinteraktion auszuführen. Es ist bekannt, dass mehrere solche Skripte existieren. Junichi Uekawa führt solch ein Skript seit 2001 aus und reichte Fehlerberichte gegen Pakete ein, die beim Test von pbuilder scheiterten. Es gab mehrere Probleme beim automatischen Erstellen:

- Build-Abhängigkeiten mussten interaktiv installiert werden, aber einige Pakete waren so kaputt, dass sie nicht ohne einzugreifen installiert werden konnten (wie PostgreSQL).

- Wenn ein Bibliothekpaket, gcc/gcj/g++ oder sogar Bison kaputtging, wurde eine große Zahl gescheiterter Builds gemeldet. (gcj-3.0, das kein »javac« hatte, Bison, das sich strenger verhielt, etc.)

- Einige Leute waren ziemlich verärgert über Berichte fehlgeschlagener Builds.

Die meisten anfänglichen Fehler wurden im pbuilder-Kehraus um das Jahr 2002 gelöst, aber von Zeit zu Zeit treten einige Übergangsprobleme auf, die eine große Zahl von Debian-Archiven beeinflussen.Regressionstests haben ihren Preis.

Ein Skript, das in der anfänglichen Ausführung von Junichi Uekawa benutzt wurde, ist im nun verbreiteten pbuilder als pbuildd.sh enthalten. Es liegt in `/usr/share/doc/pbuilder/examples/pbuildd/` und seine Konfiguration liegt in `/etc/pbuilder/pbuildd-config.sh`. Es sollte einfach genug für Leute einzurichten sein, die in pbuilder eingearbeitet sind. Es lief ziemlich lange und es sollte möglich sein, es auch auf Ihrem System einzurichten. Diese Version des Kodes ist nicht die am meisten getestete, sollte aber als Startpunkt funktionieren.

Um Pbuildd einzurichten, gibt es einige wissenswerte Punkte.

- Um das Bauen zu verhindern, muss in der Paketliste eine `./avoidlist`-Datei verfügbar sein.

- Es wird versuchen alles zu erstellen, sogar Pakete, die nicht für Ihre Architektur gedacht sind.

- Da Sie zufällige Build-Skripte ausführen, ist es besser, die Fakeroot-Option von pbuilder zu benutzen, um zu verhindern, dass das Bauen mit Root-Rechten ausgeführt wird.

- Da nicht alle Builds garantiert in einer endlichen Zeit beendet sind, ist es wahrscheinlich nötig, eine Zeitüberschreitung festzulegen, ansonsten könnte Pbuildd bei einem schlechten Build zum Stillstand kommen.

- Einige Pakete benötigen viel Plattenplatz. Circa zwei Gigabyte scheinen für den Augenblick ausreichend zu sein. Falls Sie etwas anderes entdecken, informieren Sie bitte auf Englisch den Betreuer dieser Dokumentation.

## 9. Automatische Rückportierungsskripte

Es gibt einige Leute, die pbuilder benutzen, um eine Teilmenge von Paketen automatisch auf die Distribution Stable zurückzuportieren.

Informationen darüber, wie Leute dies tun wären wünschenswert. Rückmeldungen oder Informationen, wie dies getan wird oder irgendwelche Beispiele würden begrüßt.

## 10. Pbuilder für das automatisierte Testen von Paketen benutzen

pbuilder kann benutzt werden, um Pakete automatisch zu testen. Es hat die Eigenschaft, das Platzieren von Hooks zu erlauben. Diese Hooks können innerhalb der Chroot versuchen, Pakete zu installieren, sie auszuführen oder was auch immer sonst noch getan werden kann. Einige bekannte Tests und Ideen:

- Automatische Folge von installieren, entfernen, Upgrade durchführen, entfernen, installieren, vollständig entfernen, Upgrade durchführen und vollständig entfernen (als Beispiel `B91dpkg-i` verteilt) oder nur prüfen, ob alles einigermaßen installiert (`execute_installtest.sh`).

- Automatisch Lintian ausführen (verteilt als Beispiel in `/usr/share/doc/pbuilder/examples/B90lintian`).

- Automatischer Debian-Test des Pakets? Das Paket debian-test wurde aus Debian entfernt. Eine pbuilder-Implementierung kann als debian/pbuilder-test-Verzeichnis gefunden werden, implementiert durch das Skript B92test-pkg.

Um das Skript B92test-pkg zu benutzen, fügen Sie es zuerst Ihrem Hook-Verzeichnis hinzu. [4]. Die Testdateien sind Shell-Skripte, die in `debian/pbuilder-test/NN_name` liegen (wobei NN eine Zahl ist) und dem Run-parts-Standard für Dateinamen entsprechen [5]. Nachdem sie erfolgreich gebaut wurden, werden Pakete zuerst für das Installieren und Entfernen getestet und dann wird jeder Test innerhalb der Chroot ausgeführt. Das aktuelle Verzeichnis ist das oberste Verzeichnis des Quellkodes. Das bedeutet, dass Sie voraussetzen können, dass das Verzeichnis ./debian/ aus Ihren Skripten heraus benutzt werden kann.

Beispielskripte, die mit Pbuilder-test benutzt werden können, können in `/usr/share/doc/pbuilder/examples/pbuilder-test` gefunden werden.

## 11. Pbuilder benutzen, um Builds mit alternativen Kompilern zu testen

Die meisten Pakete werden mit gcc oder g++ kompiliert und benutzen die Standardkompilerversion. Diese war für Debian GNU/Linux 3.0 (i386) Gcc 2.95. Debian 3.0 wurde jedoch mit anderen Kompilern unter Paketnamen wie gcc-3.2 für die Gcc-Kompilerversion 3.2 herausgegeben. Es war daher möglich, zu versuchen, Pakete mit verschiedenen Kompilerversionen zu kompilieren. pentium-builder stellt eine Infrastruktur bereit, um einen anderen Kompiler als den vorgegebenenen Gcc zum Bau von Paketen zu benutzen, indem es ein Wrapper-Skript bereitstellt, das Gcc heißt und den echten Gcc aufruft. Um pentium-builder in pbuilder zu benutzen, ist es möglich das Folgende in der Konfiguration einzurichten:

    EXTRAPACKAGES="pentium-builder gcc-3.2 g++-3.2"
    export DEBIAN_BUILDARCH=athlon
    export DEBIAN_BUILDGCCVER=3.2

Es wird pbuilder anweisen, das Paket pentium-builder und außerdem die GCC 3.2-Kompilerpakete innerhalb der Chroot zu installieren und die zum Funktionieren von pentium-builder benötigten Umgebungsvariablen zu setzen.

[1] debootstrap oder cdebootstrap können ausgewählt werden

[2] Die Spiegel-Site sollte möglichst ein lokaler Spiegel oder ein Zwischenspeicher-Server sein, damit die öffentlichen Spiegel nicht mit vielen Zugriffen überladen werden. Die Benutzung von Werkzeugen wie Apt-proxy ist empfehlenswert.

[3] Nur das Durchführen von Upgrades wird unterstützt. Debian unterstützt generell (noch?) kein Downgrade.

[4] Es ist möglich, die Befehlszeilenoption --hookdir /usr/share/doc/pbuilder/examples anzugeben, um ebenfalls alle Beispiel-Hooks einzufügen.

[5] Siehe run-parts(8). Zum Beispiel kein ».« in Dateinamen!

# Kapitel 3. User Mode Linux mit Pbuilder benutzen

Es ist möglich, User Mode Linux zu benutzen, indem pbuilder-user-mode-linux anstelle von pbuilder aufgerufen wird. pbuilder-user-mode-linux benötigt keine Root-Rechte und benutzt die Plattenzugriffsmethode Copy-on-write (COW) von User-mode-linux, die normalerweise wesentlich schneller ist als das traditionelle pbuilder.

User-mode-linux ist eine etwas weniger bewährte Plattform als die Standard-Unix-Werkzeuge, auf denen pbuilder beruht (chroot, tar und gzip), aber ausgereift genug, um pbuilder-user-mode-linux seit der Version 0.59 zu unterstützen. Und seitdem hat pbuilder-user-mode-linux eine schnelle Entwicklung durchlebt.

Die Konfiguration von pbuilder-user-mode-linux erfolgt in folgenden Schritten:

- Konfiguration von User Mode Linux

- Konfiguration von Rootstrap

- Konfiguration von Pbuilder-uml

## 1. User Mode Linux konfigurieren

Die Einrichtung von User Mode Linux ist nicht ganz einfach. Es wäre wahrscheinlich nützlich, wenn Sie sich selbst ein wenig darüber informieren, bevor Sie versuchen rootstrap oder pbuilder-user-mode-linux zu benutzen. Um Einzelheiten zu erfahren, lesen Sie `/usr/share/doc/uml-utilities/README.Debian` und die Dokumentation von user-mode-linux. (Sie liegt in einem gesonderten Paket, user-mode-linux-doc.)

user-mode-linux erfordert, dass der Benutzer der Gruppe »uml-net« angehört, um das Netzwerk zu konfigurieren, außer wenn Sie Slirp benutzen.

Falls Sie Ihren eigenen Kernel kompilieren, möchten Sie möglicherweise überprüfen, ob Sie Unterstützung für TUN/TAP aktiviert haben und den SKAS-Patch betrachten.

## 2. Rootstrap konfigurieren

rootstrap ist ein Wrapper um Debootstrap. Er erstellt ein Debian-Platten-Image zur Benutzung mit UML. Um Rootstrap zu konfigurieren, gibt es mehrere Anforderungen.

- Das Rootstrap-Paket installieren.

- Nur TUN/TAP: den Benutzer zur Gruppe »uml-net« hinzufügen, um Netzwerkzugriff zu gewähren

      adduser dancer uml-net

- Nur TUN/TAP: prüfen, ob der Kernel die TUN/TAP-Schnittstelle unterstützt oder, falls nötig, den Kernel neu komplilieren.

- `/etc/rootstrap/rootstrap.conf` einrichten. Falls der aktuelle Rechner beispielsweise 192.168.1.2 ist, scheint es zu funktionieren, die folgenden Einträge auf etwas wie das Folgende zu ändern.

      transport=tuntap
      interface=eth0
      gateway=192.168.1.1
      mirror=http://192.168.1.2:8081/debian
      host=192.168.1.198
      uml=192.168.1.199
      netmask=255.255.255.0

  Einige Experimente mit der Konfiguration und das Ausführen von rootstrap ~/test.uml, um es tatsächlich zu testen, wären praktisch.

  Die Benutzung vom Slirp erfordert weniger Konfiguration. Die Standardkonfiguration bringt ein funktionierendes Beispiel mit.

## 3. Pbuilder-uml konfigurieren

Das Folgende muss geschehen:

- Installation des Pakets pbuilder-uml.

- Einrichten der Konfigurationsdatei `/etc/pbuilder/pbuilder-uml.conf` auf die folgende Weise. Sie unterscheidet sich bei Slirp.

      MY_ETH0=tuntap,,,192.168.1.198
      UML_IP=192.168.1.199
      UML_NETMASK=255.255.255.0
      UML_NETWORK=192.168.1.0
      UML_BROADCAST=255.255.255.255
      UML_GATEWAY=192.168.1.1
      PBUILDER_UML_IMAGE="/home/dancer/uml-image"

  Außerdem muss sie zur Rootstrap-Konfiguration passen.

- Stellen Sie sicher, dass der Benutzer in BUILDPLACE schreiben darf. Ändern Sie BUILDPLACE in der Konfigurationsdatei auf eine Stelle, auf die der Benutzer zugreifen kann.

- Führen Sie pbuilder-user-mode-linux `create --distribution sid` aus, um das Image zu erstellen.

- Versuchen Sie pbuilder-user-mode-linux build auszuführen.

## 4. Betrachtungen, um Pbuilder-user-mode-linux auszuführen

pbuilder-user-mode-linux emuliert pbuilder größtenteils, es gibt aber einige Unterschiede.

- pbuilder-user-mode-linux unterstützt noch nicht alle Optionen von pbuilder ordentlich. Dies ist ein Problem und wird angesprochen, während besondere Bereiche entdeckt werden.

- /tmp wird innerhalb von pbuilder-user-mode-linux unterschiedlich gehandhabt. In pbuilder-user-mode-linux wird `/tmp` als Tmpfs innerhalb UML eingehängt, so dass der Zugriff auf Dateien unter `/tmp` von außerhalb des User Mode Linux nicht funktioniert. Es beeinflusst Optionen wie `--configfile` und wenn versucht wird, Pakete zu bauen, die unter `/tmp` liegen.

## 5. Paralleles Ausführen von Pbuilder-user-mode-linux

Um pbuilder-user-mode-linux parallel auf einem System auszuführen, sind ein paar Dinge zu berücksichtigen.

- Die Methoden zum Erstellen und Aktualisieren dürfen nicht laufen, wenn ein Build-Prozess läuft oder eine COW-Datei entkräftet wird.

- Falls Sie Slirp nicht benutzen, müssen parallel laufende Prozesse von User Mode Linux unterschiedliche IP-Adressen haben. Der reine Versuch, pbuilder-user-mode-linux mehrmals auszuführen, wird dazu führen, dass der Netzwerkzugriff fehlschlägt. Aber etwas wie das Folgende wird funktionieren:

      for IP in 102 103 104 105; do
        xterm -e pbuilder-user-mode-linux build --uml-ip 192.168.0.$IP \
          20030107/whizzytex_1.1.1-1.dsc &
      done

  Wenn Slirp benutzt wird, besteht dieses Problem nicht.

## 6. Pbuilder-user-mode-linux als Wrapper-Skript benutzen, um eine virtuelle Maschine zu starten

Es ist möglich, pbuilder-user-mode-linux für andere Zwecke als nur das Bauen von Debian-Paketen zu verwenden. pbuilder-user-mode-linux `login` wird einem Benutzer ermöglichen, eine Shell innerhalb des pbuilder-Basis-Images von User Mode Linux zu verwenden und pbuilder-user-mode-linux `execute` wird dem Benutzer ermöglichen, ein Skript innerhalb des Images auszuführen.

Sie können das Skript benutzen, um SSH zu installieren und einen neuen Benutzer hinzuzufügen, so dass SSH-Zugriffe innerhalb von User Mode Linux möglich sind.

Beachten Sie, dass es nicht möglich ist, ein Skript von `/tmp` zu benutzen, da pbuilder-user-mode-linux ein Tmpfs unter `/tmp` einhängt.

Das folgende Beispielskript könnte nützlich sein, um einen Sshd innerhalb von User Mode Linux zu starten.

    #!/bin/bash

    apt-get install -y ssh xbase-clients xterm
    echo "Geben Sie das Root-Passwort ein"
    passwd
    cp /etc/ssh/sshd_config{,-}
    sed 's/X11Forwarding.*/X11Forwarding yes/' /etc/ssh/sshd_config- > /etc/ssh/sshd_config

    /etc/init.d/ssh restart
    ifconfig
    echo "Zum Beenden Eingabetaste drücken"
    read

# Kapitel 4. Häufig gestellte Fragen

Hier sind bekannte Probleme und häufig gestellte Fragen dokumentiert. Dieser Teil war anfangs in der Datei README.Debian verfügbar, wurde aber hierher verschoben.

## 1. Fehlschlagen des Erstellens mit Pbuilder

Es kommt häufig vor, dass pbuilder die letzte Chroot nicht erstellen kann. Versuchen Sie ein Upgrade von pbuilder und Debootstrap durchzuführen. Es ist derzeit nicht möglich, Software zu erstellen, die die Vergangenheit handhabt. Zukunftsvorhersage ist eine Funktion, die später hinzugefügt werden könnte, wenn wir uns mit der Vergangenheit arrangieren können.

Es gibt Leute, die gelegentlich Debootstrap auf stabile Versionen zurückportieren; jagen Sie sie.

Wenn in der Debootstrap-Phase Fehler auftreten, muss das Debootstrap-Skript repariert werden. pbuilder stellt keine Möglichkeit bereit, Debootstrap zu umgehen.

## 2. Verzeichnisse, bei denen kein Bind-Mount möglich ist

Aufgrund der Weise, wie pbuilder arbeitet, gibt es viele Verzeichnisse, bei denen ein Bind-Mount beim Ausführen von pbuilder nicht möglich ist. Die Verzeichnisse umfassen `/tmp`, `/var/cache/pbuilder` und Systemverzeichnisse wie `/etc` und `/usr`. Es wird empfohlen, Verzeichnisse unter dem Home-Verzeichnis des Benutzers für Bind-Mounts zu verwenden.

## 3. In Pbuilder anmelden, um Fehlschlagen des Builds zu untersuchen

Es ist möglich, nach dem Scheitern eines Builds eine Shell-Sitzung aufzurufen. Beispiel-Hook-Skripte werden als `C10shell` und `C11screen` bereitgestellt. Das Skript C10shell wird die Bash innerhalb der Chroot starten und das Skript C11screen wird GNU screen innerhalb der Chroot starten.

## 4. In Pbuilder anmelden, um die Umgebung zu ändern

Manchmal ist es notwendig, die Chroot-Umgebung zu verändern. login wird den Inhalt der Chroot nach dem Abmelden entfernen. Es ist möglich unter Benutzung von Hook-Skripten eine Shell aufzurufen. pbuilder update führt »E«-Skripte aus und ruft beispielsweise eine Shell auf, die als `C10shell` bereitgestellt wird.

    $ mkdir ~/loginhooks
    $ cp C10shell ~/loginhooks/E10shell
    $ sudo pbuilder update --hookdir ~/loginhooks/E10shell

Außerdem ist es möglich, die Optionen `--save-after-exec` und/oder `--save-after-login` zu der pbuilder login-Sitzung hinzuzufügen, um das Ziel zu erreichen. Es ist ebenfalls möglich, die Option `--uml-login-nocow` zur Sitzung von pbuilder-user-mode-linux `login` hinzuzufügen.

## 5. BUILDRESULTUID für Sudo-Sitzungen setzen

Es ist möglich,

    BUILDRESULTUID=$SUDO_UID

in Pbuilderrc einzustellen, um BUILDRESULTUID angemessen zu setzen, wenn sudo benutzt wird.

## 6. Anmerkungen zum Gerauch von $TMPDIR

Falls Sie $TMPDIR auf einen unüblichen Wert setzen, der von `/tmp` abweicht, werden Sie bemerken, dass einige Fehler, wie das Scheitern von dpkg-source, innerhalb der Chroot auftreten.

Es gibt zwei Optionen: Sie können einen Hook installieren, um dieses Verzeichnis zu erstellen oder

    export TMPDIR=/tmp

in Pbuilderrc setzen. Suchen Sie sich eine aus.

Ein Beispielskript wird als `examples/D10tmp` mit Pbuilder bereitgestellt.

## 7. Ein Kürzel erstellen, um pbuilder mit einer speziellen Distribution auszuführen

Wenn mit mehreren Chroots gearbeitet wird, wäre es nett, mit Skripten zu arbeiten, um weniger tippen zu müssen. Ein Beispielskript `pbuilder-distribution.sh` wird als Muster bereitgestellt. Der Aufruf des Skripts mit `pbuilder-squeeze` wird pbuilder mit einer Squeeze-Chroot aufrufen.

## 8. Umgebungsvariablen benutzen, um pbuilder für eine spezielle Distribution auszuführen

Dieser Abschnitt[6] beschreibt kurz eine Möglichkeit, mehrere Pbuilder-Einrichtungen zu erstellen und zu benutzen, indem eine Pbuilderrc-Konfiguration in Ihrem Home-Pfad (`$HOME/.pbuilderrc`) erstellt und die Variable »DIST« beim Ausführen von Pbuilder oder Pdebuild benutzt wird.

Richten Sie zuerst `$HOME/.pbuilderrc` ein, dass es wie folgt aussieht:

    if [ -n "${DIST}" ]; then
            BASETGZ="`dirname $BASETGZ`/$DIST-base.tgz"
            DISTRIBUTION="$DIST"
            BUILDRESULT="/var/cache/pbuilder/$DIST/result/"
            APTCACHE="/var/cache/pbuilder/$DIST/aptcache/"
    fi

Wann auch immer Sie dann Pbuilder für eine spezielle Distribution benutzen möchten, weisen Sie »DIST« einen Wert zu, der einer der für Debian verfügbaren Distribution oder einer auf Debian basierenden Distribution, die Sie zufällig ausführen, entspricht (d.h. was auch immer unter /usr/lib/debootstrap/scripts gefunden wird).

Hier einige Beispiele der Ausführung von Pbuilder oder Pdebuild:

    DIST=gutsy sudo pbuilder create

    DIST=sid sudo pbuilder create --mirror http://http.us.debian.org/debian

    DIST=gutsy sudo pbuilder create \
            --othermirror "deb http://archive.ubuntu.com/ubuntu gutsy universe \
            multiverse"

    DIST=gutsy sudo pbuilder update

    DIST=sid sudo pbuilder update --override-config --mirror \
    http://http.us.debian.org/debian \
    --othermirror "deb http://http.us.debian.org/debian sid contrib non-free"

    DIST=gutsy pdebuild

## 9. Spezielle Listen von Apt-Quellen und lokale Pakete verwenden

Falls Sie einige außergewöhnliche Anforderungen an Ihre Apt-Einrichtung innerhalb pbuilder haben, ist es möglich, dies über die Option `--othermirror` anzugeben. Versuchen Sie etwas wie dies: `--othermirror "deb http://local/mirror stable main|deb-src http://local/source/repository ./"`

Um ein lokales Dateisystem anstelle von HTTP zu benutzen, ist es nötig, Bind-Mount zu verwenden. `--bindmounts` ist eine in solchen Fällen nützliche Befehlszeilenoption.

Es könnte vorteilhaft sein, Ihre Build-Pakete von innerhalb der Chroot zu benutzen. Es ist möglich, die Aufgabe mit der folgenden Konfiguration zu automatisieren. Richten Sie zuerst Pbuilderrc ein, um ein Bind-Mount Ihres Verzeichnisses für Build-Ergebnisse auszuführen.

    BINDMOUNTS="/var/cache/pbuilder/result"

Fügen Sie dann den folgenden Hook hinzu

    # cat /var/cache/pbuilder/hooks/D70results
    #!/bin/sh
    cd /var/cache/pbuilder/result/
    /usr/bin/dpkg-scanpackages . /dev/null > /var/cache/pbuilder/result/Packages
    /usr/bin/apt-get update

Auf diese Weise können Sie `deb file:/var/cache/pbuilder/result` benutzen

So fügen Sie einen neuen Apt-Schlüssel innerhalb der Chroot hinzu:

    sudo pbuilder --login --save-after-login
    # apt-key add - <<EOF
    ...public key goes here...
    EOF
    # logout

## 10. Pbuilder daran hindern »apt-get update« auszuführen, bevor es versucht die Build-Abhängigkeiten zu erfüllen

Sie können dafür Hook-Skripte benutzen. D-Skripte werden ausgeführt, bevor Build-Abhängigkeiten erfüllt werden.

Dieser Kodeausschnitt stammt von Ondrej Sury.

## 11. Unterschiedliche Eingabeaufforderungen innerhalb der Pbuilder-Anmeldung

Um charakteristische Bash-Eingabeaufforderungen innerhalb pbuilder zu erleichtern, ist es möglich, innerhalb der `pbuilderrc` Umgebungsvariablen wie PS1 zu setzen

Mit aktuelleren Versionen der Bash als 2.05b-2-15 ist der Wert der Variablen »debian_chroot«, falls er gesetzt ist, im Wert von PS1 (der Bash-Eingabeaufforderung) innerhalb der Chroot enthalten. In vorhergehenden Versionen der Bash,[7] funktionierte die Einstellung PS1 in Pbuilderrc.

Beispiel für »debian_chroot«:

    	export debian_chroot="pbuild$$"

Beispiel für PS1:

    	export PS1="pbuild chroot 32165 # "

## 12. Eine Chroot-Erinnerung erstellen

Bash-Eingabeaufforderungen werden Ihnen helfen, sich daran zu erinnern, dass Sie sich innerhalb der Chroot befinden. Es gibt andere Fälle, in denen Sie möglicherweise andere Hinweise bekommen möchten, dass Sie innerhalb der Chroot sind. Probieren Sie das Hook-Skript `examples/F90chrootmemo` aus. Es wird eine Datei innerhalb der Chroot erstellen, die `/CHROOT` heißt.

## 13. /var/cache/apt/archives für den Paket-Zwischenspeicher benutzen

Um Systemen mit geringer Bandbreite zu helfen, ist es möglich `/var/cache/apt/archives` als Paket-Zwischenspeicher zu benutzen. Geben Sie es einfach anstelle von `/var/cache/pbuilder/aptcache` an.

Es ist jedoch nicht möglich, dies derzeit mit der User-Mode-Linux-Version von pbuilder zu tun, da `/var/cache/apt/archives` normalerweise nur für Root schreibbar ist.

Es wird empfohlen, zugehörige Werkzeuge wie Apt-proxy zu benutzen, da das Zwischenspeichern von Paketen dem System außerhalb des Einflussbereichs von pbuilder nutzen würde.

## 14. Pbuilder auf Debian-Stable-Releases zurückportiert

Die aktuelle Stable-Rückportierung von Pbuilder ist auf backports.org verfügbar.

## 15. Warnung, dass LOGNAME nicht definiert wurde

Sie bekommen möglicherweise viele Fehlermeldungen zu Gesicht, wenn Sie pbuilder ausführen.

    	dpkg-genchanges: Warnung: kein UTMP-Eintrag verfügbar und LOGNAME nicht definiert; UID des Prozesses wird benutzt (1234)

Es ist derzeit sicher, diese Warnmeldung zu ignorieren. Bitte geben Sie eine Rückmeldung, wenn Sie ein Problem mit nicht gesetztem LOGNAME haben. LOGNAME zu setzen bereitet einige Probleme, wenn chroot aufgerufen wird. Dpkg benötigt beispielsweise Getpwnam, um innerhalb der Chroot erfolgreich zu sein, was bedeutet, dass LOGNAME und die zugehörige Benutzerinformation innerhalb der Chroot eingerichtet werden müssen.

## 16. »Build-Conflikt« mit wesentlichem Paket nicht möglich

pbuilder erlaubt derzeit kein »Build-Conflicts« mit wesentlichen Paketen. Es sollte offensichtlich sein, dass wesentliche Pakete nicht von einem funktionierenden Debian-System entfernt werden sollten und ein Quellpaket nicht versuchen sollte, das Entfernen solcher Pakete zu erzwingen, wenn Leute das Paket bauen.

## 17. Vermeiden der Nachricht »ln: Ungültiger Link über Gerätegrenzen hinweg«

Standardmäßig benutzt pbuilder harte Links, um den pbuilder-Paketzwischenspeicher zu verwalten. Es ist nicht möglich, harte Links über unterschiedliche Geräte hinweg zu erstellen. Daher wird dieser Fehler, abhängig von Ihrer Einrichtung, erscheinen. Falls dies geschieht, setzen Sie in ihrer Pbuilderrc-Datei

    APTCACHEHARDLINK=no

. Beachten Sie, dass Pakete in APTCACHE in den lokalen Chroot-Zwischenspeicher kopiert werden. Planen Sie daher genug Speicher auf dem Gerät BUILDPLACE ein.

## 18. Fakechroot benutzen

Es ist möglich, fakechroot zu benutzen, anstatt pbuilder als Root auszuführen; mehrere Dinge machen dies jedoch unpraktisch. fakechroot setzt zu ladende Bibliotheken außer Kraft und versucht, vorgegebene Libc-Funktionen außer Kraft zu setzen, wenn es die Funktionalität von virtuellem chroot bereitstellt. Einige Bibliotheken benutzen jedoch zum Funktionieren Libc nicht oder setzen das außer Kraft setzen von fakechroot außer Kraft. Ein Beispiel ist ldd. Innerhalb fakechroot wird ldd die Abhängigkeiten von Bibliotheken außerhalb der Chroot prüfen, die nicht das erwartete Verhalten aufweisen.

Um das Problem zu umgehen, hat Debootstrap eine Option `--variant fakechroot`. Benutzen Sie diese, so dass Ldd und Ldconfig überschrieben werden.

Stellen Sie sicher, dass Sie Ihrem Pfad LD_PRELOAD korrekt gesetzt haben, wie es in der Handbuchseite von Fakechroot beschrieben ist.

## 19. Debconf innerhalb von Pbuilder-Sitzungen benutzen

Um Debconf innerhalb von pbuilder zu benutzen, sollte DEBIAN_FRONTEND in `pbuilderrc` auf „readline“ zu setzen funktionieren. Es auf „dialog“ zu setzen sollte ebenfalls funktionieren. Stellen Sie aber sicher, dass Whiptail oder Dialog innerhalb der Chroot installiert sind.

## 20. »nodev«-Einhängeoptionen behindern Pbuilder-Aktivität

Falls Sie Nachrichten wie diese beim Erstellen einer Chroot sehen, sind Sie dabei, ein Dateisystem mit einer »nodev«-Option einzuhängen.

    	/var/lib/dpkg/info/base-files.postinst: /dev/null: Keine Berechtigung

Sie werden außerdem Probleme haben, falls Sie ein Dateisystem mit der Option »noexec« oder »nosuid« einhängen. Stellen Sie sicher, dass Sie diese Schalter nicht gesetzt haben, wenn Sie das Dateisystem für `/var/cache/pbuilder` oder $BUILDPLACE einhängen.

Dies ist kein Problem, wenn Sie user-mode-linux benutzen.

Sehen Sie zum Beispiel 316135 .

## 21. Pbuilder ist langsam

pbuilder ist öfters langsam. Der langsamste Teil von pbuilder ist bei jedem Aufruf von pbuilder das Extrahieren des tar.gz. Dies kann verhindert werden, indem pbuilder-user-mode-linux benutzt wird. pbuilder-user-mode-linux benutzt ein COW-Dateisystem und muss daher das Wurzeldateisystem nicht aufräumen und neu erstellen.

pbuilder-user-mode-linux ist langsamer beim Ausführen des tatsächlichen Build-Systems, aufgrund des üblichen Mehraufwands von user-mode-linux für Systemaufrufe. Es ist freundlicher zur Festplatte.

pbuilder mit Cowdancer ist ebenfalls eine Alternative, die die Geschwindigkeit des Pbuilder-Starts verbessert.

## 22. Pdebuild zum Fördern eines Pakets benutzen

Um ein Paket zu signieren, dass es für die Förderung gekennzeichnet ist, ist es möglich, die Optionen`--auto-debsign` und `--debsign-k` von pdebuild zu benutzen.

    	pdebuild  --auto-debsign  --debsign-k XXXXXXXX

## 23. Warum liegt in ../ eine source.changes-Datei?

Wenn pdebuild ausgeführt wird, wird pbuilder Dpkg-buildpackage ausführen, um ein Debian-Quellpaket zu erstellen, das an pbuilder weitergereicht wird. Eine Datei mit Namen XXXX_YYY_source.changes ist das, was von diesem Prozess übrigbleibt. Das ist harmlos, solange Sie nicht versuchen, sie in das Debian-Archiv hochzuladen.

Dieses Verhalten ist anders, wenn es mittels `--use-pdebuild-internal` ausgeführt wird

## 24. Die Modi »amd64« und »i386«

AMD64-Architekturen sind fähig, Programme im i386-Modus auszuführen. Es ist möglich, pbuilder zu benutzen, um Pakete auszuführen, indem die Optionen linux32 und debootstrap `--arch` benutzt werden. Im Besonderen wird eine Befehlszeilenoption wie die Folgende funktionieren.

    pbuilder create --distribution sid --debootstrapopts --arch --debootstrapopts i386 \
      --basetgz /var/cache/pbuilder/base-i386.tgz --mirror http://deb.debian.org/debian
    linux32 pbuilder build --basetgz /var/cache/pbuilder/base-i386.tgz

## 25. Tmpfs für »buildplace« benutzen

Um die Ausführgeschwindigkeit zu verbessern, ist es möglich, Tmpfs für den Build-Ort von Pbuilder zu verwenden. Hängen Sie das Tmpfs in `/var/cache/pbuilder/build` ein und setzen Sie

    APTCACHEHARDLINK=no

.

## 26. Svn-buildpackage zusammen mit Pbuilder benutzen

Der Befehl Pdebuild kann mit der Befehlszeilenoption »svn-buildpackage --svn-builder« benutzt werden. [8]

    alias svn-cowbuilder="svn-buildpackage --svn-builder='pdebuild --pbuilder cowbuilder"

[6] Dieser Teil der Dokumentation wurde von Andres Mejia beigetragen.

Dieses Beispiel wurde von einem Wiki übernommen (https://wiki.ubuntu.com/PbuilderHowto).

[7] Versionen der Bash seit und vor Debian 3.0.

[8] Zack hat diesem Blog ein Beispiel gesandt.

# Kapitel 5. Fehlerbehebung und Entwicklung

## 1. Fehler berichten

Um Fehler zu berichten, wäre es wichtig, ein Protokoll darüber zu haben, was schiefgelaufen ist. Meistens sollte das Hinzufügen einer Option `--debug` und das erneute Ausführen der Sitzung den Zweck erfüllen. Bitte senden Sie das Protokoll einer solchen Sitzung zusammen mit Ihrer auf Englisch verfassten Problembeschreibung, um den Prozess der Fehlersuche zu erleichtern.

## 2. Mailingliste

Es gibt auf Alioth eine Maillingliste für Pbuilder (pbuilder-maint@lists.alioth.debian.org). Sie können sie über die Alioth-Webseite abonnieren. http://alioth.debian.org/mail/?group_id=30778.

## 3. IRC-Kanal

Zur Koordinierung und Kommunikation wird der IRC-Kanal #pbuilder auf irc.oftc.net benutzt. Bitte legen Sie dort Ihre Absicht dar, wenn Sie mit irgendwelchen Änderungen beginnen oder irgendeine Änderung übertragen.

## 4. Informationen für Pbuilder-Entwickler

Dieser Abschnitt versucht, aktuelle Vorgehensweisen bei der Entwicklungs zu dokumentieren und wie Dinge allgemein in der Entwicklung funktionieren.

pbuilder wird mitbetreut mit Ressourcen, die auf Alioth bereitgestellt werden. Es gibt eine Alioth-Projektseite unter http://alioth.debian.org/projects/pbuilder. Außerdem ist die Homepage, die diesen Text zeigt, unter http://alioth.debian.org/projects/pbuilder verfügbar. Das Git-Depot ist über HTTP, Git oder (falls Sie ein Alioth-Konto haben) SSH verfügbar.

    git-clone git://git.debian.org/git/pbuilder/pbuilder.git
    git-clone http://git.debian.org/git/pbuilder/pbuilder.git
    git-clone ssh://git.debian.org/git/pbuilder/pbuilder.git

Die Git-Commit-Nachricht sollte zuerst eine Zeile haben, die beschreibt, was das Commit tut. Dies sollte wie »debian/changelog« formatiert sein, da es mittels Git-dch wortgetreu in das Changelog kopiert wird. Die zweite Zeile ist leer und der Rest sollte die Hintergrund- und Zusatzinformationen im Zusammenhang mit der Implementierung des Commits beschreiben.

Test-Suites sind im Verzeichnis `./testsuite/` verfügbar. Von Änderungen wird erwartet, dass sie die Test-Suites nicht fehlschlagen lassen. `./run-test.sh` ist eine Basistest-Suite, die eine Zusammenfassung in `run-test.log` und `run-test-cdebootstrap.log` ablegt. `./run-test-regression.sh` ist eine Regressionstest-Suite, die das Ergebnis in `run-test-regression.log` ablegt. Derzeit wird run-test.sh täglich automatisch ausgeführt, um sicherzustellen, dass Pbuilder funktioniert.

Tabelle 5.1. Verzeichnisstruktur der Test-Suite

Verzeichnis | Bedeutung
--- | ---
`./testsuite/` | Verzeichnis für Test-Suite.
`./testsuite/run-test.sh` | Täglicher Regressionstest, um zu prüfen, ob Änderungen am Debian-Archiv Pbuilder unterbrechen.
`./testsuite/run-test.log` | Eine Zusammenfassung der Test-Suite.
`./testsuite/normal/` | Verzeichnis für Test-Suite-Ergebnisse für die Ausführung von Pbuilder mit Debootstrap.
`./testsuite/cdebootstrap/` | Verzeichnis für Test-Suite-Ergebnisse für die Ausführung von Pbuilder mit Cdebootstrap.
`./testsuite/run-regression.sh` | Regressionstest-Suite, wird jedesmal ausgeführt, wenn etwas an Pbuilder geändert wurde, um sicherzustellen, dass es keinen Rückschritt gibt.
`./testsuite/run-regression.log` | Zusammenfassung des Testergebnisses.
`./testsuite/regression/BugID-*.sh` | Regressionstests, Rückgabewert 0 bei Erfolg, 1 bei Fehlschlag.
`./testsuite/regression/BugID-*` | Dateien, die für die Regressionstest-Suite verwendet werden.
`./testsuite/regression/log/BugID-*.sh.log` | Ausgabe des Regressionstests; Ausgabe des Skripts wird durch run-regression.sh umgeleitet.

Wenn Änderungen vorgenommen werden, sollten die Änderungen im Git-Commit-Protokoll dokumentiert werden. Git-dch wird aus dem Commit-Protokoll debian/changelog generieren. Schreiben Sie eine aussagekräftige erste Zeile in Ihr Commit-Protokoll und fügen Sie jede verfügbare Information zum Schließen von Fehlern hinzu. debian/changelog sollte nicht direkt bearbeitet werden, außer wenn eine neue Version veröffentlicht wird.

Eine TODO-Datei ist in `debian/TODO` verfügbar. Sie wird meist nicht gut gepflegt, wird aber hoffentlich aktueller sein, wenn Leute beginnen, sie zu benutzen. Zum Bearbeiten der Datei wird der Emacs-Todoo-Modus verwandt.

Wenn eine neue Version von pbuilder veröffentlicht wird, ist die Version mit der Git-Markierung X.XXX (Versionsnummer) gekennzeichnet. Dies wird mit dem Skript ./git-tag.sh, das im Quellkode-Verzeichnisbaum verfügbar ist, erledigt.

# Kapitel 6. Andere Verwendungen von Pbuilder

## 1. Pbuilder für kleine Experimente benutzen

Es gibt Fälle, in denen es nötig ist, ein wenig zu experimentieren und Sie das Hauptsystem nicht beschädigen wollen, wie das Installieren experimenteller Bibliothekspakete oder das Kompilieren mit experimentellen Kompilern. Für diese Fälle steht der Befehl pbuilder login zur Verfügung.

pbuilder login ist eine Funktion zur Fehlersuche für pbuilder selbst, aber es ermöglicht Benutzern außerdem eine temporäre Chroot zu verwenden.

Beachten Sie, dass die Chroot nach dem Abmelden aus der Shell bereinigt wird und das Einhängen von Dateisystemen innerhalb der Chroot als schädlich angesehen wird.

## 2. Kleine Programme innerhalb der Chroot ausführen

Um die Benutzung von pbuilder für andere Zwecke zu erleichtern, ist pbuilder execute verfügbar. pbuilder execute wird ein im Befehlszeilenargument angegebenes Skript nehmen und innerhalb der Chroot aufrufen.

Das Skript kann nützlich für Abfolgen von Operationen, wie das Installieren von SSH oder das Hinzufügen eines neuen Benutzers innerhalb der Chroot, sein.

# Kapitel 7. Experimentelle oder »wishlist«-Funktionen von Pbuilder

Es gibt einige fortgeschrittene Funktionen, die über die Grundfunktionen von pbuilder für einige besondere Zwecke hinausgehen.

## 1. LVM benutzen

LVM2 hat eine nützliche Schnappschussfunktion, die Copy-on-write-Images zeigt. Dies kann für pbuilder ebenso wie für die User-Mode-Linux-Portierung von pbuilder benutzt werden. Das Skript »lvmpbuilder« in den Beispielen implementiert solch eine Portierung. Die Skripte und Dokumentation finden Sie unter `/usr/share/doc/pbuilder/examples/lvmpbuilder/`.

## 2. Cowdancer benutzen

cowdancer erlaubt Copy-on-write-Semantiken auf dem Dateisystem unter Benutzung von harten Links und Hard-link-breaking-on-write-Tricks. pbuilder scheint bei der Benutzung von cowdancer viel schneller zu sein und es ist ein idealer Punkt für Verbesserungen. cowbuilder, ein Wrapper für pbuilder, um cowdancer zu benutzen, ist im Paket cowdancer seit Version 0.14 verfügbar.

Beispielshafte Befehlszeilen für Cowbuilder sehen aus wie folgt:

    # cowbuilder --create --distribution sid
    # cowbuilder --update --distribution sid
    # cowbuilder --build XXX.dsc

Es ist außerdem möglich, Cowdancer mit dem Befehl »pdebuild« zu benutzen. Geben Sie es mit der Befehlszeilenoptionen `--pbuilder` an oder setzen Sie es in der Konfigurationsoption PDEBUILD_PBUILDER.

    $ pdebuild --pbuilder cowbuilder

## 3. Pbuilder ohne tar.gz verwenden

Die Option `--no-targz` von pbuilder wird den Gebrauch von pbuilder auf eine andere als die übliche Weise ermöglichen. Sie wird versuchen eine existierende Chroot zu benutzen und sie nach der Arbeit damit nicht zu bereinigen. Es ist ein Betriebsmodus, der eher sbuild gleicht.

Es sollte möglich sein, Basis-Chroot-Images für dchroot mit den folgenden Befehlen zu erstellen:

    # pbuilder create --distribution lenny --no-targz --basetgz /chroot/lenny
    # pbuilder create --distribution squeeze --no-targz --basetgz /chroot/squeeze
    # pbuilder create --distribution sid --no-targz --basetgz /chroot/sid

## 4. PBuilder in einem Vserver verwenden

Es ist möglich, pbuilder in einer Vserver-Umgebung zu verwenden. Dies erfordert entweder Vserver-patches in Version 2.1.1-rc14 oder höher oder eine Linux-Kernel-Version 2.6.16 oder höher.

Um pbuilder in einem Vserver zu verwenden, müssen Sie in den ccapabilities dieses Servers secure_mount CAPS setzen.

## 5. Gebrauch von Ccache

Es ist möglich, den Zwischenspeicher des C-Kompilers ccache zu verwenden, um wiederholte Builds für einige Pakete zu beschleunigen (oder Pakete, die die aus irgendeinem Grund die gleichen Dateien mehrmals kompilieren). Die Verwendung von ccache kann das wiederholte Bauen großer Pakete auf Kosten von etwas Plattenplatz und Buchführung drastisch beschleunigen.

Um die Benutzung von ccache mit pbuilder zu aktivieren, sollten Sie CCACHEDIR in Ihrer Pbuilderrc setzen.

Die aktuelle Implementierung der ccache-Unterstützung hat einige Fehler, nämlich dass CCACHEDIR dem pbuilder Builduser gehören muss und dass das parallele Ausführen von pbuilder nicht unterstützt wird. Deshalb ist es standardmäßig nicht eingeschaltet.

# Kapitel 8. Referenzmaterial

## 1. Verzeichnisstruktur außerhalb der Chroot

Tabelle 8.1. Verzeichnisstruktur außerhalb der Chroot

Verzeichnis | Bedeutung
--- | ---
`/etc/pbuilderrc` | Konfigurationsdatei.
`/usr/share/pbuilder/pbuilderrc` | Standardkonfiguration.
`/var/cache/pbuilder/base.tgz` | Standardspeicherort, den Pbuilder für base.tgz benutzt. Dieser Tarball enthält eine Basis-Debian-Installation ausschließlich mit Build-essential-Paketen.
`/var/cache/pbuilder/build/PID/` | Standardspeicherort, den Pbuilder für Chroot benutzt.
`/var/cache/pbuilder/aptcache` | Standardspeicherort, den pbuilder als APT-Zwischenspeicher benutzen wird, um Deb-Pakete zu abzulegen, die pbuilder während des Bauens benötigt.
`/var/cache/pbuilder/ccache` | Standardspeicherort, den pbuilder als Zwischenspeicher benutzen wird.
`/var/cache/pbuilder/result` | Standardspeicherort, in den pbuilder die Deb-Dateien und andere Dateien ablegt, die nach dem Build erzeugt werden.
`/var/cache/pbuilder/pbuilder-umlresult` | Standardspeicherort, in den pbuilder-user-mode-linux die Deb-Dateien und andere Dateien ablegt, die nach dem Build erzeugt werden.
`/var/cache/pbuilder/pbuilder-mnt` | Standardspeicherort, den pbuilder-user-mode-linux benutzt, um das COW-Dateisystem für die Chroot einzuhängen.
`/tmp` | pbuilder-user-mode-linux wird Tmpfs für die Arbeit einhängen.
`${HOME}/tmp/PID.cow` | pbuilder-user-mode-linux benutzt dieses Verzeichnis als Speicherort des COW-Dateisystems.
`${HOME}/uml-image` | pbuilder-user-mode-linux benutzt dieses Verzeichnis für das vollständige User-Mode-Linux-Image.

## 2. Verzeichnisstruktur innerhalb der Chroot

Tabelle 8.2. Verzeichnisstruktur innerhalb der Chroot

Verzeichnis | Bedeutung
--- | ---
`/etc/mtab` | Symbolischer Link zu `/proc/mounts`.
`/tmp/buildd` | Standardort, der vom pbuilder benutzt wird, um die zu verarbeitenden Debian-Pakete abzulegen. `/tmp/buildd/packagename-version/` wird das Wurzelverzeichnis des Pakets sein, das verarbeitet wird. Die Umgebungsvariable HOME wird von Pbuilder-buildpackage auf diesen Wert gesetzt. `--inputfile` wird die Dateien hier ablegen.
`/runscript` | Das Skript, das als Argument zur Ausführung an pbuilder übergeben wird, wird weitergereicht.
`/tmp/hooks` | Der Speicherort von Hooks.
`/var/cache/apt/archives` | pbuilder kopiert den Inhalt dieses Verzeichnisses zu und vom Aptcache-Verzeichnis außerhalb der Chroot.
`/var/cache/pbuilder/ccache` | pbuilder hängt dieses Verzeichnis per Bind-Mount ein, damit es durch Ccache benutzt wird.
`/tmp/XXXX` | pbuilder-user-mode-linux benutzt ein Skript in `/tmp` für ein Bootstrap in User Mode Linux.

# Kapitel 9. Nebensächliche archäologische Einzelheiten

## 1. Dokumentations-Chronik

Die Arbeit an diesem Dokument wurde am 28. Dezember 2002 durch Junichi Uekawa begonnen, der versuchte zu dokumentieren, was über pbuilder bekannt ist.

Diese Dokumentation ist im Quell-Tarball und im Git-Depot (Web-basierter Zugriff ist möglich) von pbuilder verfügbar. Eine Kopie dieser Dokumentation können Sie auf der Alioth-Projektseite für Pbuilder finden. Dort gibt es auch eine PDF-Version. Die Homepage für pbuilder wird vom Alioth-Projekt auf http://pbuilder.alioth.debian.org/ gehostet.

Die Dokumentation wurde unter Verwendung von DocBook-XML mit dem Emacs-PSGML-Modus und unter Verwendung von Wysidocbookxml zur Echtzeitvorschau geschrieben.

## 2. Möglicherweise ungenaue Hintergrundgeschichte von Pbuilder

Das Folgende ist ein möglichst genauer Bericht, wie es zu pbuilder kam und andere Versuche, ein Ergebnis wie pbuilder zu erzielen. Dieser Teil des Dokuments war ursprünglich in der Datei AUTHORS, um dem Anerkennung zu zollen, was vor pbuilder existierte.

### 2.1. Zeit vor Pbuilder

Es gab einst Dbuild, ein Shell-Skript, um Debian-Pakete aus der Quelle zu bauen. Lars Wirzenius schrieb dieses Skript und es war gut, kurz und (wahrscheinlich) einfach. Es gab damals (vermutlich) nichts wie Build-Abhängigkeiten und es war simpel. Es könnte verbessert worden sein, jedoch konnten nur Referenzen und keine tatsächliche Quelle gefunden werden.

Debbuild wurde wahrscheinlich von James Troup geschrieben. Genau bekannt ist dies nicht, da der tatsächliche Kode nicht vorliegt. Es konnten nur einige Referenzen im Netz und in den Maillinglist-Protokollen gefunden werden.

Sbuild ist ein Perl-Skript, um Debian-Pakete aus der Quelle zu bauen. Es wertet Build-Abhängigkeiten aus, führt verschiedene andere Prüfungen durch und hat viele Hacks, um Dinge tatsächlich zu bauen, einschließlich einer Tabelle, welches Paket benutzt wird, wenn virtuelle Pakete angegeben wurden (tut es dies immer noch?). Es unterstützt den Gebrauch einer lokalen Datenbank für Pakete, die keine Build-Abhängigkeiten haben. Es wurde von Ronan Hodek geschrieben und es wurde wahrscheinlich von vielen Leuten repariert und erweitert. Es ist Teil von Wanna-Build und wird intensiv im Debian-Build-System benutzt. Es wurde vermutlich überwiegend von Ryan Murray betreut.

### 2.2. Geburt von Pbuilder

Wanna-Build (Sbuild) war (in der Zeit um das Jahr 2001) ziemlich schwierig einzurichten und es war ein nie Debian-Paket. Dbuild war etwas, was Build-Abhängigkeiten vorwegnahm.

Pakete aus den Quellen unter Benutzung von Build-Abhängigkeitsinformationen innerhalb einer Chroot zu bauen klang trivial und pbuilder war geboren. Es war ursprünglich ein Shell-Skript mit nur wenigen Zeilen, das Debootstrap, Chroot und Dpkg-buildpackage im gleichen Durchlauf aufrief, aber bald wurde entschieden, dass das zu langsam sei.

Ja, und es dauerte fast ein Jahr, um einige Dinge in Ordnung zu bringen und mitten in diesem Prozess wurde Debian 3.0 veröffentlicht. Juhu. Debian 3.0 konnte nicht vollständig mit pbuilder gebaut werden, aber die Anzahl der Pakete, die nicht gebaut werden können, nimmt stetig ab (hoffentlich).

### 2.3. Und sein zweites Lebensjahr

Jemand wollte, dass pbuilder nicht als Root ausgeführt wird und als User Mode Linux im Laufe der Zeit nützlicher wurde, wurde begonnen, mit pbuilder-user-mode-linux zu experimentieren. pbuilder-user-mode-linux blieb nicht so funktional wie gewünscht und der Bootstrap der user-mode-linux-Umgebung erwies sich als ziemlich hart aufgrund der Qualität des Kodes von User Mode Linux oder der Paketierung zu dieser Zeit, die auf die eine oder andere Art die Netzwerkunterstützung zerstörte.

### 2.4. Das fünfte Jahr von Pbuilder

pbuilder wird nun weitgehend als »Beinahe-Standardwerkzeug« zum Testen und Bauen von Paketen in einer unberührten Umgebung angenommen. Es gibt andere ähnliche Werkzeuge, die ähnliche Aufgaben erledigen, aber sie verfolgen nicht das gleiche Ziel. Deshalb wird pbuilder nun von mehreren Leuten mitbetreut.

sbuild ist nun ein gut betreutes Debian-Paket innerhalb von Debian und mit pbuilder als solch langsamem Monster bevorzugen einige Leute den Ansatz von Sbuild. Es besteht die Hoffnung, dass die Entwicklung LVM-Schnappschüsse, Cowloop oder Cowdancer zu benutzen, die Situation etwas verbessert.