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.

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).

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).

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)

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.

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.

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.

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:

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:

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.

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.

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:

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.

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.

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.

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 Folgende muss geschehen:

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

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

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

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.

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.

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.

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.

Es ist möglich,

BUILDRESULTUID=$SUDO_UID

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

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.

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.

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

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

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.

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 # "

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.

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.

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

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.

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.

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.

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.

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.

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 .

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.

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

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

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

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

.

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

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

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.

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.

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.

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.

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.

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.

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.

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/.

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

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

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.

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.

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.

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.