Autobuilder-Netz

Das Autobuilder-Netz ist eine Debian-Entwicklung, die die Paket-Übersetzung für alle Architekturen verwaltet, die Debian derzeit unterstützt. Dieses Netz besteht aus mehreren Maschinen, die ein spezielles Software-Paket namens buildd verwenden, um Pakete aus dem Debian-Archiv herauszuholen und sie für die Ziel-Architektur neu zu bauen.

Warum wird das Autobuilder-Netz benötigt?

Die Debian-Distribution unterstützt etliche Architekturen, aber die Paket-Betreuer kompilieren Binärversionen gewöhnlich nur für eine einzige Architektur, zu der sie Zugriff haben (normalerweise i386 oder Amd64). Die anderen Builds werden automatisch erstellt, wobei sichergestellt wird, dass jedes Paket nur einmal gebaut wird. Fehler werden in der Autobuilder-Datenbank gelistet und verfolgt.

Als Debian/m68k (die erste nicht-Intel-Portierung) begann, mussten m68k-Entwickler nach neuen Paket-Versionen Ausschau halten und diese rekompilieren, falls sie zu der Intel-Distribution synchron bleiben wollten. Dies wurde alles manuell durchgeführt: Entwickler beobachteten die Upload-Mailingliste für neue Pakete und nahmen einige von ihnen, um sie zu bauen. Die Koordination, dass kein Paket zweimal von verschiedenen Leuten gebaut wurde, geschah über Ankündigungen auf einer Mailingliste. Es ist offensichtlich, dass diese Prozedur fehlerbehaftet und zeitraubend ist. Dies war allerdings lange der normale Weg, um nicht-i386-Distributionen aktuell zu halten.

Das build-Daemon-System automatisiert den Großteil dieses Prozesses. Es besteht aus einer Reihe von Skripten (die in Perl und Python geschrieben sind), die sich im Laufe der Zeit entwickelt haben, um den Portierern bei verschiedenen Aufgaben zu helfen. Sie haben sich schließlich zu einem System entwickelt, das in der Lage ist, Debian-Distributionen fast automatisch aktuell zu halten. Die Sicherheits-Aktualisierungen werden auf den gleichen Maschinen gebaut, um sicherzustellen, dass sie zeitnah verfügbar sind.

Wie funktioniert buildd?

Buildd ist der Name, der normalerweise der vom Autobuilder-Netz verwandten Software gegeben wird, aber tatsächlich besteht es aus einer Reihe von verschiedenen Teilen:

wanna-build
ein Werkzeug, dass bei der Koordination des (Neu-)Bauens über eine Datenbank hilft, die eine Liste von Paketen und ihrem Status enthält. Dort ist eine zentrale Datenbank pro Architektur vorhanden, die Paket-Status, Versionen und einige andere Informationen speichert. Sie wird mit Quell- und Paketdateien gefüttert, welche von verschiedenen Paketarchiven, die für Debian existieren (z.B. ftp-master und security-master), empfangen werden.
buildd
ein Daemon, der periodisch die von wanna-build verwaltete Datenbank überprüft und sbuild aufruft, um Pakete zu bauen. Nachdem das Bauprotokoll vom Buildd-Administrator bestätigt wurde, wird er das Paket in das korrekte Archiv hochladen.
sbuild
ist für die eigentliche Übersetzung von Paketen in isolierten Chroots zuständig. Es stellt sicher, dass alle benötigten Quellabhängigkeiten vor dem Bau in die Chroot installiert sind und ruft dann die Standard-Debian-Werkzeuge auf, um den Bauprozess zu starten. Bauprotokolle werden bei der Bauprotokolldatenbank eingereicht.

Alle diese Teile arbeiten zusammen, um das Buildd-Netz zum Laufen zu bekommen.

Was muss ein Debian-Entwickler machen?

In der Tat muss ein durchschnittlicher Debian-Entwickler das buildd-Netz nicht explizit benutzen. Immer wenn er ein Paket in das Archiv hochlädt (binär übersetzt für eine gegebene Architektur), wird es zu der Datenbank für alle Architekturen (im Zustand Needs-Build) hinzugefügt. Bau-Maschinen fragen die Datenbank nach Paketen in diesem Zustand ab und werden routinemäßig Pakete von dieser Liste nehmen. Die Liste wird nach vorherigem Übersetzungszustand (entweder out-of-date (nicht aktuell) oder uncompiled (unkompiliert)), Priorität, Abschnitt und schließlich Paketnamen priorisiert. Um das Verhungern von einigen Paketen am Ende der Warteschlange zu vermeiden, werden die Prioritäten dynamisch mit wachsender Wartezeit in der Warteschlange angepasst.

Falls der Bau auf allen Architekturen gelingt, braucht der Betreuer nichts zu machen. Alle diese Binärpakete werden in das korrespondierende Archiv hochgeladen. Falls der Bau nicht gelingt, kommt das Paket in einen speziellen Zustand (Build-Attempted für Baufehler, die noch nicht geprüft wurden, Failed für geprüfte und eingereichte Fehler im Paket oder Dep-Wait, falls das Paket spezielle Bau-Abhängigkeiten hat, die nicht verfügbar sind). Der Administrator des Autobuilders wird die Pakete, die nicht bauen, durchsehen und wird dies dem Betreuer zurückmelden, gewöhnlich indem er einen Fehler in der Fehlerdatenbank eröffnet.

Manchmal braucht ein Paket lange, um auf einer gegebenen Architektur zu bauen und dies hält das Paket vom Übergang nach Testing ab. Falls ein Paket einen Übergang aufhält, werden die Bauprioritäten normalerweise auf Bitten des Veröffentlichungsteams angepasst. Andere Bitten werden nicht akzeptiert, da die zunehmende Wartezeit bereits automatisch zu einer höheren Baupriorität führt.

Sie können den Status verschiedener buildd-Versuche von Paketen, die zu einem bestimmten Betreuer gehören, überprüfen, indem Sie die buildd-Protokolle überprüfen. Diese Protokolle sind auch vom Paket-Betreuer-Überblick aus verlinkt.

Für weitere Informationen über die verschiedenen Zustände, in denen ein Paket sein kann, lesen Sie bitte die wanna-build-Zustände.

Wo kann ich weitere Informationen finden?

Natürlich sind sowohl die Dokumentation als auch der Quellcode, der für diese verschiedenen Werkzeuge verfügbar ist, der beste Weg um herauszufinden, wie das buildd-Netz arbeitet. Zusätzlich enthält der Portieren und portiert werden-Abschnitt der Debian-Entwicklerreferenz ergänzende Informationen über die Funktionsweise und stellt auch einige Informationen über Paket-Bauer und Portierungs-Werkzeuge bereit, die sowohl an dem Prozess des Aufsetzens wie auch der Wartung des buildd-Netzes beteiligt sind.

Auf der Buildd-Statusseite sind einige Statistiken über das Autobuilder-Netz verfügbar.

Wie kann ich meinen eigenen Auto-Builder-Knoten aufsetzen?

Es gibt mehrere Gründe, warum ein Entwickler (oder Benutzer) einen Autobuilder aufsetzen und betreiben möchte:

Sie können weitere Informationen darüber lesen, wie Sie einen Autobuilder aufsetzen.

Die Buildd-Administratoren kontaktieren

Die Administratoren, die für die Buildds einer bestimmten Architektur verantwortlich sind, können unter arch@buildd.debian.org erreicht werden, zum Beispiel i386@buildd.debian.org.


Diese Einführung in das Autobuilder-Netz wurde geschrieben mit Teilen und Stücken bereitgestellt von Roman Hodek, Christian T. Steigies, Wouter Verhelst, Andreas Barth, Francesco Paolo Lovergine, Javier Fernández-Sanguino und Philipp Kern.