Bemerkung: Das Original ist neuer als diese Übersetzung.
Kurzdarstellung des Betriebs des Autobuilder-Netzes
Im Herzen des Systems befindet sich die wanna-build-Datenbank, die die Versionen und Zustände im Auge behält. quinn-diff vergleicht nach jeder Archivaktualisierung 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-Daemons (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 Daemons gesandt. Er schaut das Protokoll durch und entscheidet, was mit dem Paket geschehen soll: es hochzuladen, es auf Failed oder Dep-Wait zu setzen und es erneut zu versuchen, usw. ... Falls eine positive Bestätigung (eine signierte .changes-Datei) erhalten wird, verschiebt der Daemon 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 und bei der automatischen Installation der Bauabhängigkeiten, wie sie von dem zu bauenden Paketen angefordert werden.
Inhalt entwickelt von Roman Hodek für den 6. Internationalen Linux-Kongress 1999, er wurde 2009 von Philipp Kern leicht aktualisiert, um die derzeitige Realität ein bisschen besser wiederzugeben