Im Herzen des Systems befindet sich die wanna-build-Datenbank, die die Versionen und Zustände im Auge behält. quinn-diff vergleicht jeden Tage die Paketliste für die Zielarchitektur gegen die Liste der Quellpakete und füttert die Liste der Pakete, die einer Neuübersetzung bedürfen, in die Datenbank, wo sie den Zustand Needs-Build annehmen.
Alle Bau-Deamons (es kann mehr als einen geben) befragen regelmäßig die Datenbank bezüglich solcher Pakete und nehmen einige von ihnen, so dass diese in den Zustand Building kommen. Natürlich können auch Menschen Pakete nehmen, z.B. in Spezialfällen wenn eine automatische Übersetzung nicht möglich ist. Hier sehen wir auch den zweiten Zweck von wanna-build: Es stellt sicher, dass die gleiche Version eines Pakets nicht zweimal gebaut wird.
Falls alles gut geht, kann später ein fertiges Paket hochgeladen werden, was ein anderer Zustand (Uploaded) ist. Danach wird es schließlich in das Debian-Archiv installiert, so dass es in der aktualisierten Paketliste für die Zielarchitektur auftaucht. Diese Liste wird mit der Datenbank vereinigt, so dass das Paket in den Zustand Installed übergeht und dort bleibt, bis zur nächsten Version des Quellpakets.
Es gibt eine Reihe von weiteren Zuständen, darunter: Failed ist für Pakete, die auf Grund von Fehlern in den Quellen nicht gebaut werden konnten und es wird erwartet, dass die Fehler in einer Folgeversion behoben wurden (natürlich nachdem das Problem berichtet wurde). Daher wird eine neue Version direkt in Needs-Build eintreten, aber mit einer Warnung, dass etwas mit der vorhergehenden Version nicht gestimmt hat. Zusammen mit dem Zustand wird eine Fehlerbeschreibung gespeichert. Der Zustand Dep-Wait wird verwendet, wenn ein Paket einige andere Pakete zum Übersetzen benötigt aber diese noch nicht verfügbar sind und vorher gebaut werden müssen. Dieser Zustand speichert eine Liste von benötigten Paketen und eventuell Versionen, und wenn von allen bekannt ist, dass sie installiert wurden, ändert sich der Zustand zurück in Needs-Build.
.Wie wir bereits gesehen haben, nimmt der Bau-Daemon Pakete aus der Datenbank zum übersetzen. Nun wollen wir etwas genauer hinschauen: Falls er einige Pakete zum Bauen hat, verwendet er sbuild für den eigentliche Compilierungsprozess, und für jeden Bau wird ein Protokoll an den Betreuer des Deamons gesandt. Er schaut das Protokoll durch und entscheidet, was mit dem Paket geschehen soll: es hochzuladen, es auf Failed oder Dep-Wait zu setzen, einige Änderungen an den Quellabhängigkeiten vorzunehmen und es erneut zu versuchen, usw. ... Falls eine positive Bestätigung erhalten wird, verschiebt der Deamon es in ein Hochlade-Verzeichnis, von wo aus alle Pakete über einen Cron-Job hochgeladen werden.
Ein Blick auf die Protokolldateien ist der einzige menschliche Eingriff
falls keine Fehler passieren. Es gibt zwei gute Gründe, dies nicht weiter
zu automatisieren: Erstens endet ein Bau manchmal mit einem Ergebnis
OK
, aber der Bau versagte nichtsdestotrotz aus Gründen, die für
die Maschine unsichtbar sind. Und zweitens würde direktes Hochladen
ein automatisches PGP-signieren der erzeugten Dateien erzwingen, wobei der
Schlüssel auf der Bau-Maschine kein Mantra hätte. I hielt dies für ein
nicht-akzeptierbares Sicherheitsloch.
Das Bau-Skript sbuild ruft mehr oder weniger nur einige Standard Debian-Werkzeuge auf, um die Quellen zu übersetzen. Es hilft auch bei einigen häufigen Arbeiten und der Buchführung, aber die wirklich besondere Sache von ihm sind die Quellabhängigkeiten. Oft benötigen Pakete andere Pakete installiert, um zu compilieren, beispielsweise Compiler und Bibliotheken. Es ist nicht praktisch, alle diese Pakete ständig installiert zu haben, und oft ist es aufgrund von Konflikten sogar nicht möglich. Die Quellabhängigkeiten teilen sbuild für jedes Paket mit, welche anderen Pakete benötigt werden. Es kann diese dann automatisch vor dem Bau installieren und sie danach wieder entfernen.
Die Quellabhängigkeitenliste kann teilweise auch automatisch generiert werden, indem die Abhängigkeiten des aus den Quellen erzeugten Binärpakets angeschaut werden. Dies ist die Aufgabe von andrea, die die i386-Paketliste nach Abhängigkeiten untersucht und Bibliothekspakete auf Entwicklungspaketnamen abbildet. Es vereinigt die Ergebnisse mit händischen Ergänzungen für Dinge, die nicht automatisch erzeugt werden können, wie Compiler oder spezielle Werkzeuge.
Inhalt entwickelt von Roman Hodek für den 6. Internationalen Linux-Kongress 1999
