Viele Linux-Distributoren stützen sich zur Qualitätssicherung auf einen zentralen, vollzeitlich engagierten Entwicklerstamm. Die Quelltext-basierte Distribution Gentoo zeigt, wie eine stärkere Beteiligung der Community mit der Tradition bricht und dennoch stabile Ergebnisse liefert.

Jede Linux-Distribution muss einen Kompromiss zwischen zwei konkurrierenden Zielen finden: Einerseits wünschen sich die Benutzer aktuelle Versionen der enthaltenen Software. Auf der anderen Seite erwarten sie von Linux kompromisslose Stabilität. Doch die lässt sich nur durch rigides Qualitätsmanagement erzielen, das zwangsläufig die Entwicklung verlangsamt.

Die meisten Distributionen durchlaufen zyklisch für jede Version eine Betatestphase. Die Quellcode-basierte Distribution Gentoo [1] kommt jedoch ohne die üblichen Releases aus: Versionen existieren nur für die Installationsmedien, die Komponenten eines laufenden Systems lassen sich mit dem Paketmanager Portage [2] jederzeit updaten.

Nach der Betaphase im zyklischen Release-Modell sind selten noch alle Pakete aktuell. Die kontinuierliche Entwicklung bei Gentoo bietet dagegen die Möglichkeit, auf neue Versionen flexibel zu reagieren. Dass die Distribution die Testphase auf einzelne Pakete bezieht, erleichtert zudem die Einbindung nicht vollzeitlich engagierter Entwickler. Gentoo kann daher die Community stärker einbinden als andere Distribution, bei denen die Mitarbeit oft auf das Einsenden von Bugreports beschränkt bleibt.

Kompilieren ohne Benutzereingriff

Qualitätsprobleme ergeben sich bei auf Binärpaketen basierenden Distributionen wie Debian, Ubuntu oder Suse oft aus den Abhängigkeiten zwischen den vorkompilierten Paketen. Das Paketmanagement-System Portage installiert die Software jedoch auf der Grundlage des Quellcode. Die Paketdefinitionen liegen als kompakte Shellskripte (so genannte Ebuilds) vor. Sie enthalten Informationen und Codefragmente, die es der Paketverwaltung ermöglichen, den Quellcode herunterzuladen, zu kompilieren und zu installieren (Abbildung 1). Binäre Abhängigkeiten entstehen erst auf dem Rechner des Anwenders.

Abbildung 1: Anders als die meisten Paketmanager installiert Portage keine vorkompilierten Binärpakete, sondern baut jedes Paket auf dem Rechner des Anwenders aus den Quellen. Portage kümmert sich dabei um Abhängigkeiten und automatisiert den Übersetzungsprozess.

So reicht innerhalb eines Ebuild zum Beispiel die Angabe »DEPEND=dev-libs/openssl«, um sicherzustellen, dass Portage die OpenSSL-Bibliothek installiert, bevor es das neue Paket einspielt. Weil dieses erst auf dem Rechner des Anwenders gegen die vorhandene Version von OpenSSL kompiliert wird, ist eine Angabe der Versionsnummer nicht nötig, solange sich das API der Bibliothek nicht verändert. Folglich lassen sich auch experimentelle Pakete mit komplexen Abhängigkeiten ohne große Probleme in das System integrieren.

Die Freiheit bezahlt Portage aber mit erhöhtem Zeit- und Ressourcenbedarf. Für viele Pakete gibt es zwar alternativ eine vorkompilierte Version. Gentoo-spezifische Vorteile wie Aktualität und Optimierung auf den eigenen Prozessor bieten die Binärpakete jedoch nicht.

Die Paketdefinitionen, die Grundlage für das automatisierte Übersetzen, stellt Gentoo in einem zentralen CVS-Baum zur Verfügung. Die Nutzer können ihr System täglich aktualisieren. Diese dynamische Paketverwaltung erleichtert die Weiterentwicklung der Distribution, hat jedoch andererseits gravierende Auswirkungen auf die Stabilität: Jeder Fehler im CVS-Baum macht sich sofort bei den Nutzern bemerkbar.

Qualitätsmanagement

Um die Herausforderung zu meistern, die durch den direkten Zugriff der Nutzer auf den zentralen Paketbaum entsteht, hat Gentoo eigene Maßnahmen zur Qualitätssicherung entwickelt: Die Software Repoman [3] überprüft neue Ebuilds auf typische Unachtsamkeiten. Hat der Entwickler zum Beispiel Abhängigkeiten zu Bibliotheken auf eine Version beschränkt, die im Portage-Baum nicht vorhanden ist, bemerkt dies Repoman vor dem Commit.

Pakete lassen sich für jede von Gentoo unterstützte Architektur separat als stabil, instabil oder maskiert kennzeichnen. Ein Paket erreicht den stabilen Zustand nicht ohne Ablauf der vorherigen instabilen Testphase.

Das Entwicklungsmodell von Gentoo bietet auf Grund seiner Konzentration auf einzelne Pakete beste Voraussetzungen für eine starke Einbindung der Community. Um Fehler in dem zentralen CVS-Tree zu vermeiden, müssen sich neue Entwickler allerdings erst bewähren, bevor sie Schreibzugriff erhalten. Bei Gentoo hat sich hierfür ein festes Verfahren etabliert.

Abbildung 2: Mit so genannten Overlays ermöglicht es Gentoo, experimentelle Pakete aus bestimmten Themenbereichen in ein ansonsten stabiles System einzubinden.

Drum prüfe, wer …

Wer Gentoo-Entwickler werden möchte, sollte zunächst mit dem Team, das für das anvisierte Themengebiet zuständig ist, Kontakt aufnehmen und sich mit neuen Ebuilds oder wichtigen Fixes vorstellen und beteiligen.

Sind die bereits aktiven Entwickler zu der Überzeugung gekommen, dass die Zusammenarbeit gut funktioniert, kann sich der künftige Mitarbeiter für den Entwicklerstatus bewerben. Ein Eintrag im Bugtracker gibt der Community 30 Tage lang die Möglichkeit, sich zu der Bewerbung zu äußern. Danach beweist der Bewerber durch Beantwortung eines Quiz [4], dass er über die Grundlagen der Ebuild-Entwicklung Bescheid weiß. Nun folgt eine weitere Testphase, bei der der Neuling bereits Schreibzugriff auf das CVS-Repository hat.

Gentoo trennt außerdem das Qualitätsmanagement von der eingentlichen Entwicklung: Nicht die Entwickler selbst markieren ihre Pakete als stabil. Spezielle Architektur-Teams, auf deren Testmaschinen ausschließlich stabile Pakete installiert sind, übernehmen diese Aufgabe. Eigenständige Qualitätsmanagement-Teams überprüfen zusätzlich laufend die Arbeit der Entwickler.

Die Einführung der Architektur-Teams hat die Stabilität der Distribution deutlich erhöht. Auf der anderen Seite hat sich der Zeitraum, der vergeht, bis neue Pakete die Stabil-Kennzeichnung erhalten, merklich verlängert.

Dass dadurch auch die Qualitätsanforderungen für instabile Pakete stark gestiegen sind, schränkt letzten Endes die Testmöglichkeiten der Entwickler ein. Zusätzlich mehren sich Anfragen der Benutzer, bestimmte Softwarepakte als stabil zu markieren.

Doch Gentoo versteht den zentralen CVS-Baum keineswegs mehr als Spielwiese. Aktualisierungen, die zu Problemen bei den Benutzern führen, sollen strikt vermieden werden. Als Ausweg aus diesem Dilemma dient eine neue Funktion der Paketverwaltung Portage, die so genannten Overlays.

Strikt nach Thema

Overlays enthalten alternative, experimentelle Paketdefinitionen. Wie der Name andeutet, überdecken sie die Pakete des gewöhnlichen Portage-Baums. Overlays bieten Entwicklern und Nutzern deutlich mehr Spielraum für Experimente als das durch gestiegene Stabilitätsforderungen eingeschränkte zentrale Repository.

Die Variable »PORTAGE_OVERLAYS« in der zentralen Konfigurationsdatei »/etc/make.conf« des Gentoo-Systems kann den Pfad zu einem oder mehreren Overlays enthalten. Der stabile Paketbaum lässt sich damit problemlos um experimentelle Pakete erweitern. Wegen der im Vergleich zu Binärpaketen reduzierten Abhängigkeiten lassen sich selbst zentrale Bibliotheken patchen. Der Benutzer kann die Modifikationen testen, ohne Gefahr zu laufen, mit einem unbrauchbaren System zu enden.

Katalysator

Anfänglich nutzten vor allem die Entwickler selbst das Overlay-System, um Paketdefinitionen zum Testen in das eigene System einzubinden. Es erschien jedoch nahe liegend, die privaten Entwickler-Overlays im Web zu veröffentlichen: Interessierten Nutzern stehen so die neuesten Versionen der Paketdefinitionen zur Verfügung und den Entwicklern gehen bei Problemen frühzeitig Rückmeldungen zu. Ein weiterer Vorteil aus Sicht der Entwickler ist, dass die Qualitätsanforderungen des zentralen CVS-Baums nicht ihre Arbeit behindern. Um die Community verstärkt einzubinden, vergibt Gentoo Schreibrechte für Overlays ohne aufwändige Testphase. Das Qualitätsmanagement bleibt auf ein Mindestmaß reduziert. Sobald ein Ebuild innerhalb eines Overlay die nötige Stabilität erreicht, wandert es gut getestet in den CVS-Baum.

Auch für die Nutzer ergibt sich ein Vorteil: Sie können sich für Overlays aus bestimmten Themenbereichen entscheiden und in begrenztem Umfang die neueste Software einbinden, ohne die Stabilität des Gesamtsystems zu gefährden.

Overlays verbessern außerdem die Interaktion zwischen Entwicklern und Nutzern: Das Hinzufügen einer experimentellen PHP-Version zum zentralen CVS-Baum würde auch Nutzer, die keinerlei Erfahrung mit PHP haben, mit auftretenden Problemen konfrontieren. Neben der abschreckenden Wirkung auf unerfahrene Anwender zöge dies auch eine Vielzahl schwer nachvollziehbarer Problemberichte nach sich. Die interessierten Nutzer, die sich gezielt Overlays nach Themenbereichen aussuchen, können Fehler meist genauer lokalisieren. Bugs lassen sich damit erheblich schneller korrigieren.

Overlays sind außerdem erste Anlaufstellen für künftige Gentoo-Entwickler: Da bei den Overlays jeder Anwender mitarbeiten kann, bieten sie bereits aktiven Entwicklern die Möglichkeit, Kontakt zu potenziellen neuen Mitarbeitern an der Kerndistribution aufzunehmen.

Für binärbasierte Distributionen ist es schwieriger, mit ähnlichen Strukturen zu arbeiten, da deren ausgeprägtere Paketabhängigkeiten stärker nach einem zentralen Qualitätsmanagement verlangen. Automatisierte Build-Server – etwa die Open Suse Build Services [5], die Community-Mitgliedern eine standardisierte Entwicklungs- und Testumgebung bieten – sind ein in jüngster Zeit unternommener Versuch, die Entwicklung binärer Distributionen auf eine ebenso breite Basis zu stellen.

Das verminderte Qualitätsmanagement in den Overlays bringt allerdings auch ein Sicherheitsrisiko mit sich: Es wäre recht unproblematisch, in den enthaltenen Ebuilds Schadcode unterzubringen. Sicher zu benutzen sind die Paketdefinitionen eines Overlay also eigentlich nur nach eigenhändiger manueller Überprüfung. Die wird allerdings kaum ein Anwender nach jedem Update durchführen. Letztlich bleibt also nur das Vertrauen auf die gemeinschaftliche Kontrolle durch alle Nutzer eines Overlay.

Ohne Barrieren

Bisher verhinderte mangelnder Komfort eine stärkere Verbreitung der Overlays. Viele waren im Internet schwer zu finden, außerdem musste der Anwender zum Einbinden die Konfigurationsdatei des Paketmanagers per Hand anpassen. Ein neues Portal [6] bietet nun einen Überblick über verfügbare Overlays (siehe Abbildung 3).

Abbildung 3: Die neue Webseite unter [6] bietet einen Überblick über verfügbare Overlays. Für jedes Overlay findet sich ein Kommentar, der die zuletzt eingespielten Fixes beschreibt.

Die Software Layman [7] vereinfacht zusätzlich die Einbindung (Abbildung 4). Das Tool holt eine Liste aller verfügbaren Overlays von einem zentralen Server und bietet dem Nutzer die Möglichkeit, beliebig viele davon einzubinden: »layman -L« listet die verfügbaren Overlays auf, »layman -a php« bindet beispielsweise das experimentelle PHP-Overlay ein, »layman -s php« bringt es bei Bedarf auf den neuesten Stand. Derzeit lassen sich über Layman mehr als fünfzig Overlays installieren.

Abbildung 4: Die Anwendung Layman vereinfacht den Umgang mit Overlays. Über einen Befehlsaufruf bindet sie sämtliche Pakete aus einem Overlay zu einem bestimmten Themenbereich (zum Beispiel experimentelle Pakete für Software-Entwickler) in das System ein.

Mit zunehmender Anzahl der experimentellen Projekte erhöht sich allerdings auch die Wahrscheinlichkeit, dass nicht miteinander kompatible Paketdefinitionen aufeinander treffen: Gegenwärtig gibt es keine Möglichkeit, solche Konflikte zwischen Paketen aus unterschiedlichen Overlays automatisch aufzulösen oder zu vermeiden.

Fazit

Die Quellen-basierte Paketverwaltung von Gentoo stellt das Qualitätsmanagement vor spezifische Herausforderungen, die sich von den bei binären Distributionen auftretenden Problemen unterscheiden. Gentoo hat eigene Mechanismen zur Qualitätssicherung entwickelt: Die Zulassung neuer Entwickler mit Schreibzugriff auf das zentrale CVS-Repository folgt einem festgelegten Schema. Von den eigentlichen Entwicklern unabhängige Teams treffen die Entscheidung, ein Paket nach einer Testphase als stabil auszuzeichnen. Die Kombination aus stabilem CVS-Baum und themenorientierten Overlays bietet dem Nutzer außerdem die Möglichkeit, nach seinen Bedürfnissen ein sehr aktuelles und doch stabiles System zusammenzustellen.

Für Entwickler schaffen Overlays mehr Freiraum für Experimente, ohne die Stabilität der Kerndistribution zu gefährden. Da spezialisierte Overlays einen Nutzerstamm mit überdurchschnittlichem Know-how gewinnen, lassen sich neue Pakete effektiver testen. Die Testphase im Overlay erhöht die Qualität der Pakete im zentralen Portage-Baum.

Für bereits aktive Entwickler bietet die Spielwiese eines Overlay, bei der auch Einsteiger willkommen sind, Gelegenheit, neue Entwickler kennen zu lernen und als Mitarbeiter für die Kerndistribution zu gewinnen. (pkr)