Inhaltsverzeichnis
Tabellenverzeichnis
Inhaltsverzeichnis
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.
Inhaltsverzeichnis
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.
pbuilder create wird einen Basis-Chroot-Tarball
(base.tgz) erstellen. 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 minimale Debian-Installation 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 will update the base.tgz. It will extract the chroot, invoke apt-get update and apt-get dist-upgrade inside the chroot, and then recreate the base.tgz (the base tar-ball).
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 auf 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 auf 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 geschickterweise 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 auf 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 ist mit dem aktuellen Benutzer außerhalb der Chroot ausgeführt worden.
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
gelesen. 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
Systemeinstellungen aufhebt. Als Vorsichtsmaßnahme, wenn Sie über irgendeine
Konfiguration verfügen, müssen Sie die Konfiguration so optimieren, dass sie
bei einem Upgrade mit neuen Versionen von Pbuilder funktioniert.
pbuilder requires full root privilege when it is satisfying the build-dependencies, but most packages do not need root privilege to build, or even refused to build when they are built as root. pbuilder can create a user which is only used inside pbuilder and use that user id when building, and use the fakeroot command when root privilege is required.
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:
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.
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.
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:
Automatic install-remove-install-purge-upgrade-remove-upgrade-purge
test-suite (distributed as an example, B91dpkg-i
), or
just check that everything installs somewhat
(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.
To use B92test-pkg script, first, add it to your hook directory.
[4]. The test files are shell scripts
placed in debian/pbuilder-test/NN_name
(where NN is a
number) following run-parts standard[5]
for file names. After a successful build, packages are first tested for
installation and removal, and then each test is ran inside the chroot. The
current directory is the top directory of the source-code. This means you
can expect to be able to use ./debian/ directory from inside your scripts.
Example scripts for use with pbuilder-test can be found in
/usr/share/doc/pbuilder/examples/pbuilder-test
.
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 weitergegeben. 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!
Inhaltsverzeichnis
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
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 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.
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.
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.
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.
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
Inhaltsverzeichnis
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.
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.
It is possible to invoke a shell session after a build failure. Example
hook scripts are provided as C10shell
and
C11screen
scripts. C10shell script will start bash
inside chroot, and C11screen script will start GNU screen inside the chroot.
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.
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 geladene 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, die
die Optionen linux32 und debootstrap
--arch
benutzen. 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://ftp.jp.debian.org/debian linux32 pbuilder build --basetgz /var/cache/pbuilder/base-i386.tgz
Um die Geschwindigkeit der Operation 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"
[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
Inhaltsverzeichnis
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-Web-Schnittstelle 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 auf die Weise 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
unterbrechen. ./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, wurde 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 verwandt werden |
./testsuite/regression/log/BugID-*.sh.log | Ausgabe des Regressionstests, Ausgabe des Skripts, an das durch run-regression.sh weitergeleitet wurde |
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 wurde mit dem Skript ./git-tag.sh, das im Quellkode-Verzeichnisbaum verfügbar ist, erledigt.
Inhaltsverzeichnis
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.
Inhaltsverzeichnis
Es gibt einige fortgeschrittene Funktionen, die über die Grundfunktionen von pbuilder für einige besondere Zwecke hinausgehen.
LVM2 has a useful snapshot function that features Copy-on-write images.
That could be used for pbuilder just as it can be used
for the user-mode-linux pbuilder port. lvmpbuilder
script in the examples directory implements such port. The scripts and
documentation can be found under
/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.
It is possible to use C compiler cache ccache to speed up repeated builds of the same package (or packages that compile the same files multiple times for some reason). Using ccache can speed up repeated building of large packages dramatically, at the cost of some disk space and bookkeeping.
To enable usage of ccache with pbuilder, you should set CCACHEDIR in your pbuilderrc file.
Current implementation of ccache support has several bugs, that CCACHEDIR must be owned by the pbuilder build user, and parallel runs of pbuilder is not supported. Therefore it is not enabled by default.
Inhaltsverzeichnis
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 speichern, 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-Dateisystem. |
${HOME}/uml-image | pbuilder-user-mode-linux benutzt dieses Verzeichnis für das vollständige User-Mode-Linux-Image. |
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. |
Inhaltsverzeichnis
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 http://pbuilder.alioth.debian.org/ vom Alioth-Projekt 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.
Es gab einst Dbuild, das war 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 (vermutlich) nichts wie Build-Abhängigkeiten und es war simpel. Es konnte verbessert werden, es 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ächlich 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 wird vermutlich überwiegend von Ryan Murray betreut.
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).
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 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.
pbuilder wird nun weitgehend als »Beinahe-Standardwerkzeug« zum Testen von Paketen und dem 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. Um dieser Tatsache zu gedenken, 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 das Näherkommen von Sbuild. Es besteht die Hoffnung, dass die Entwicklung, um LVM-Schnappschüsse oder Cowdancer zu benutzen, die Situation etwas verbessert.