Die Woche: Debian: Umarmen statt überrollen
Debian ist als solide Linux-Distribution mit erprobter und daher älterer Software bekannt. Wer einen neueren Entwicklungsstand bevorzugt, wechselt daher zu den Debian-Derivaten. Mit einem zweiten Release-Zweig wollen die Debianer künftig mit Ubuntu und Co. konkurrieren.
Für brandaktuelle Software ist das jeweils aktuelle Stable Release von Debian Linux wahrlich nicht berühmt, sondern für verlässliche, lange erprobte, kurzum gut abgehangene Software. Dazu passen auch die Release-Zyklen von zwei oder mehr Jahren zwischen zwei Stable-Versionen, in denen das jeweils aktuelle Debian nur behutsam gepflegt, entlaust und mit Security-Fixes versorgt wird. Neue Programmversionen oder neue Kernel-Versionen mit neuen Treibern sucht man vergebens.
Das mag Versions-Fetischisten abtörnen, doch für Benutzer, die den Computer nur als Werkzeug für ihre Arbeit einsetzen, oder den Administratoren, die einen Stapel Server zu verwalten haben, sind Stabilität und lange Release-Zyklen zentrale Auswahlkriterien. Zumal man bei Debian duchaus einzelne Programmversionen aus den Testing- oder Unstable-Repositories nachinstallieren kann, wenn es einmal erforderlich sein sollte – während der Rest des Systems weiterhin aus lange erprobter Software besteht. Alternativ kann man mit wenigen Befehlen ganz auf Debian Testing oder den Entwicklerzweig Debian Unstable alias Sid wechseln, muss dann aber damit rechnen, dass man gelegentlich auf Probleme und Fehler stößt. Ausgangsbasis bleibt jedoch immer das aktuelle Stable Release.
Auf Debian basierende Linux-Distributionen wie Linux Mint Debian Edition, Aptosid oder Ubuntu haben ihre eigenen Vorstellungen bezüglich Aktualität und Stabilität der Software: So verwendet Linux Mint den Testing-Zweig von Debian, aus dem am Ende des Entwicklungszyklus das nächste Debian Stable Release entsteht. Aptosid geht sogar noch einen Schritt weiter und bedient sich aus dem Unstable-Zweig. Bei Ubuntu gibt es keine klare Trennung, neben eigenen Paketen mixt man hier verschiedene Versionsstände zu einem Ubuntu-Release zusammen. Da der größte Teil der Software von Debian übernommen wird, spricht man bei den drei Distributionen auch von Debian-Derivaten.
Das Verhältnis der Debian-Gemeinde zu den Derivaten ist seit je her belastet, manche Debian-Entwickler empfinden sie als Schmarotzer, die die Früchte des Debian-Projekts ernten, ohne es durch eigene Patches oder Erweiterungen voran zu bringen. Als einen der Gründe für die Entwicklung der vielen Debian-Derivate ermittelte Debian-Projektleiter Stefano Zacchiroli das Fehlen eines Debian-Release mit aktuellen Programmversionen – für Testing und Unstable gibt es nämlich keine offiziellen Releases mit aktueller Software, entweder man aktualisiert ein Stable Release oder muss zu einem der Snapshots wie dem Daily oder Weekly Build greifen.
Derzeit diskutieren die Debianer auf der Entwickler-Mailing-Liste, ob man den aktuellen Testing-Zweig nicht künftig unter dem Namen "Debian Rolling" in regelmäßigen Abständen als zweites offizielles Release veröffentlichen sollte. Unter anderem verspricht man sich davon mehr qualifizierte Bug-Reports als heute, könnten doch dann erfahrene Debian-Anwender "Rolling" auf Produktivsystemen einsetzen. Doch ein solches Rolling Release bedeutet auch eine Menge zusätzlichen Aufwand: So müsste ein neu zu gründendes Release-Team regelmäßig den aktuellen Testing-Entwicklungsstand einfrieren, einen Fork generieren und dort alle für ein Release nötigen Änderungen einpflegen. Will man einen Fork für jedes Rolling Release vermeiden, so müsste man den aktuellen Testing-Entwicklungszweig für einige Monate einfrieren, womit andere Debian-Entwickler blockiert würden, weil sie zum Beispiel neue Funktionen in dieser Zeit nicht einpflegen können.
Und das Ergebnis? Ein offizielles Debian-Release, das sich kaum von einem Linux Mint oder einem Aptosid unterscheidet. Die Nutzerzahlen Debian-basierter Linux-Distributionen wird man durch die Einführung von Debian Rolling kaum steigern, sondern höchstens den einen oder anderen Anwender von einem Debian-Derivat zurück zum Original locken.
Doch ist nicht auch ein Debian-Derivat letztlich ein Debian? Nach der Ansicht Zacchirolis hätten zumindest die Entwickler von Linux Mint und Aptosid nicht einfach ein eigenes Derivat auf die Beine stellen, sondern lieber die Debian-Gemeinde von der Notwendigkeit einer solchen Distribution überzeugen sollen – wobei die aktuelle Diskussion zeigt, wie schwierig so etwas ist. Doch dafür ist es zu spät, die Arbeit ist getan und die Derivate sind erfolgreich – erfolgreicher sogar als das Original.
Und wenn die Derivate ihre eigenen Patches pflegen, ohne sie an das Debian-Projekt zurückzureichen, sollte man sich Gedanken darüber machen, woran das liegt. Vielleicht ist der Prozess für Neulinge einfach zu kompliziert, sind die Anforderungen zu hoch? Gerade das Einreichen sauberer Patches, die sich anstandslos in den aktuellen Quellenbaum auf dem Debian-Server einspielen lassen, ist bei Forks nicht immer einfach. Vielleicht muss man dann als Debian-Maintainer einen Schritt auf die Derivate-Entwickler zugehen und versuchen, die gleiche Code-Basis wiederherzustellen, sodass man künftig keinen Fork mehr benötigt, sondern womöglich mit ein paar Compiler-Schaltern auskommt. Man sollte also lieber die Zusammenarbeit mit den Derivaten verbessern, anstatt sie als Konkurrenz zu betrachten und mit einem Rolling Release platt zu walzen. Denn letztlich entwickeln alle für und mit Debian-Quellen – und sind somit im Grunde auch Debian-Entwickler. (mid) (mid)
