Start   Impressum   Lizenz         online lesen   Download         Online-Shop   Jumping Blue Turtle

Debian für Unternehmer - Debian-Know-how

0150: Debian-Releases im Überblick

Debian verwendet eine speziell für die Debian-Philosophie maßgeschneiderte Release-Verwaltung.

Lesen Sie nun leichtverdaulich das, was Sie wissen müssen, um die Release-Verwaltung von Debian zu verstehen.

1. Debian-Distributionen

Debian ist zwar eine von vielen Linux-Distributionen, aber im Jargon von Debian hat der Name "Distribution" noch eine weitere Bedeutung. Um Missverständnisse zu vermeiden, unterscheide ich fortan zwischen:

Debian betreibt mehrere Debian-Distributionen parallel. Die Debian-Distributionen unstable, testing, stable und oldstable existieren ständig. Die Debian-Distribution experimental existiert bei Bedarf.

1.1. "experimental"

Wenn experimental überhaupt existiert, dann ist es nicht vollständig. Es wird benötigt, wenn radikale Änderungen am System untersucht werden müssen. Und es enthält dann nur die Pakete, die für die spezielle Untersuchung benötigt werden.

1.2. "unstable"

Neue Versionen von Paketen und Programmen werden zuerst in unstable integriert. Hier werden sie im laufenden Betrieb getestet. Die Debian-Anwender, die ein unstable auf ihren Rechnern am Laufen haben, sind in der Regel diejenigen, die die offensichtlichen oder sogar schweren Fehler, die die neuen Versionen mitbringen können, zuerst entdecken.

Weil die in unstable enthaltenen Pakete und Programme unaufhörlich aktualisiert werden, verschwinden die in neuen Paket- und Programm-Versionen entdeckten Fehler in unstable in der Regel (durch die Integration nachfolgender Versionen) nach einer gewissen Zeit automatisch.

1.3. "testing"

Wenn sich eine neue Paket- oder Programm-Version nach genau definierten Kriterien in unstable bewährt hat (sie keine gravierenden Fehler mehr enthält), dann wandert sie nach testing.

Solange sich testing nicht im Zustand "freeze" befindet, kann die Schwelle zwischen unstable und testing als eine Art Filter angesehen werden, der dafür sorgt, dass zwar (ähnlich wie in unstable) die in testing enthaltenen Pakete und Programme unaufhörlich aktualisiert werden, aber die neuen Paket- und Programm-Versionen keine offensichtlichen, schweren Fehler enthalten.

Die Debian-Anwender, die ein testing auf ihren Rechnern am Laufen haben, entdecken in der Regel nicht ganz so offensichtliche Fehler.

Nach ein paar Monaten (oder wenigen Jahren) wird die unaufhörliche Aktualisierung der in testing enthaltenen Pakete und Programme gestoppt. Diese Debian-Distribution wird dann eingefroren (erhält den Zustand "freeze"). Ab diesem Zustand ist der Filter nicht mehr durchlässig und es werden nur noch Fehler beseitigt, die während der Anwendung von testing entdeckt werden. Nur noch in wenigen Ausnahmen werden Änderungen aus unstable übernommen.

1.4. "stable"

Während der meisten Zeit werden überhaupt keine neuen Paket- oder Programm-Versionen in stable aufgenommen. Daher auch der Name "stable": Diese Debian-Distribution ändert sich so gut wie gar nicht.

Ausnahme: Wenn Sicherheitslücken entdeckt werden, die sich in stable befinden, dann werden sogenannte Security-Updates für stable erstellt. Diese Security-Updates wandern meistens mit dem nächsten dist-upgrade (von apt-get oder aptitude) auf die Rechner derjenigen Debian-Anwender, die ein stable betreiben. Wenn sich genügend Security-Updates angesammelt haben, erscheint eine neue Revision.

Wenn sich testing lange genug im Zustand "freeze" befunden hat, dann sind nach einer gewissen Zeit alle release-kritischen Fehler im testing beseitigt. Wenn das der Fall ist, dann geschieht Folgendes:

  1. Alle in stable befindlichen Pakete und Programme wandern nach oldstable.
  2. Alle neuen Paket- und Programm-Versionen wandern von testing nach stable. Zu diesem Zeitpunkt sind testing und stable identisch.
  3. In testing wird der Zustand "freeze" aufgehoben. Von nun an ist der Filter wieder durchlässig und es wandern unaufhörlich bewährte neue Paket- und Programm-Versionen von unstable nach testing.
1.5. "oldstable"

Diese Debian-Distribution enthält immer den jeweils vorherigen Zustand von stable. Nachdem die neuen Paket- und Programm-Versionen von testing nach stable gewandert sind, haben die bisherigen Anwender von stable die Möglichkeit, selbst den Zeitpunkt zu bestimmen, wann die Änderungen in stable auch auf ihre Rechner eingespielt werden. Brauchen Sie noch etwas Zeit, dann bleiben sie bei oldstable. Wenn sie soweit sind, auf die neuen Paket- und Programm-Versionen zu aktualisieren, dann steigen sie auf stable um.

2. Debian-Releases

In der Regel hat jede Debian-Distribution einen eindeutigen Namen. Alle Namen kommen aus einem Film namens "Toy Story". Der Name von unstable ändert sich nie: Er lautet immer sid. Sid ist in dem Film der kleine Junge von nebenan, der immer alles kaputt macht. Zu unstable passt dieser Name daher sehr gut.

Die Namen von testing, stable und oldstable ändern sich immer dann, wenn neue Paket- und Programm-Versionen von testing nach stable wandern (siehe oben). Dann passiert Folgendes:

  • Es findet ein Release statt.
  • Die Debian-Distribution oldstable, deren Aufgabe es ist, ständig das "alte Release" zu repräsentieren, übernimmt den Namen, die Release-Nummer und die Inhalte von stable.
  • Die Debian-Distribution stable, deren Aufgabe es ist, ständig das "aktuelle Release" zu repräsentieren, übernimmt den Namen, die Release-Nummer und die Inhalte von testing.
  • Die Debian-Distribution testing, deren Aufgabe es ist, ständig das "kommende Release" zu repräsentieren, bekommt einen neuen Namen und im Laufe der Zeit eine neue Release-Nummer. Bei einem kommenden Release wird erst mit der Zeit klar, wie bedeutend dieses Release sein wird. Dementsprechend wird die genaue Release-Nummer erst recht spät festgelegt. Die Beschaffenheit der nächsten Release-Nummer wird davon abhängen, ob sich an ihr das Major- oder das Minor-Release, also die Zahl vor oder die Zahl nach dem ersten Punkt ändern wird.

Die nachfolgende Liste enthält zu allen bisher stattgefundenen Releases die Release-Nummern, die Namen und jeweils das Release-Datum:

  • Release 1.1 (buzz): 17.06.1996
  • Release 1.2 (rex): 12.12.1996
  • Release 1.3 (bo): 05.06.1997
  • Release 2.0 (hamm): 24.07.1998
  • Release 2.1 (slink): 09.03.1999
  • Release 2.2 (potato): 15.08.2000
  • Release 3.0 (woody): 19.07.2002
  • Release 3.1 (sarge): 06.06.2005
  • Release 4.0 (etch): 08.04.2007
  • Release 5.0 (lenny): 14.02.2009

Die nachfolgende Liste enthält zu den in naher Zukunft noch stattfindenden Releases die Release-Nummern, die Namen und jeweils das geplante Release-Datum, falls eins bekannt ist:

  • Release unbekannt (squeeze): unbekannt

3. Der feine Unterschied zwischen Distribution und Release

Wenn Sie eine Entscheidung treffen wollen, mit welchem "Debian" Sie einen Rechner betreiben werden, dann sollten Sie zuallererst den Unterschied kennen zwischen:

  • Debian-Distribution
  • Debian-Release

Sie können sich für eine der beiden "Mengen" entscheiden, sollten aber wissen, welche Konsequenzen Ihre Entscheidung dann hat.

An einem Beispiel zeige ich Ihnen nun Ihre Optionen und welche Konsequenzen diese Optionen haben:
Am 01.01.2009 sah die Situation so aus:

  • Die Debian-Distribution unstable hatte (wie eigentlich immer) den Namen sid.
  • Die Debian-Distribution testing hatte den Namen lenny.
  • Die Debian-Distribution stable hatte den Namen etch.
  • Die Debian-Distribution oldstable hatte den Namen sarge.

Jetzt gehen wir die Optionen der Reihe nach durch.

3.1. Sie entscheiden sich für eine Debian-Distribution

Wenn Sie sich am 01.01.2009 für eine Debian-Distribution entschieden hätten, dann hätten Sie die Wahl gehabt zwischen:

  • unstable: Mit unstable bekommen Sie automatisch immer ein sid.
  • testing: Am 01.01.2009 hätten Sie mit testing automatisch ein lenny bekommen. An dem Tag, an dem das nächste Debian-Release erscheint, würde sich nach einem Dist-Upgrade Ihr System von einem lenny zu einem squeeze verwandeln. Im Grunde würde bei einem Dist-Upgrade das passieren, was immer bei einem Dist-Upgrade auf einem testing-System passiert: Sie würden (wie gewohnt) die letzten Änderungen an den Paketen und Programmen erhalten.
  • stable: Am 01.01.2009 hätten Sie mit stable automatisch ein etch bekommen. An dem Tag, an dem das nächste Debian-Release erscheint, würde sich nach einem Dist-Upgrade Ihr System von einem etch zu einem lenny verwandeln. Im Klartext heißt das: Für die nächsten Minuten oder gar Stunden würde ihr System nun komplett umgekrempelt werden. Alle Pakete und Programme würden jetzt auf den Stand von lenny gebracht werden. Danach würden fast alle Ihrer Anwendungen anders aussehen und es könnte passieren, dass einige Programme gar nicht mehr laufen. Auf jeden Fall würden Sie, wenn Sie das Release nicht mitbekommen würden, spätestens jetzt eine sehr böse Überraschung erleben!!!
  • oldstable: Am 01.01.2009 hätten Sie mit oldstable automatisch ein sarge bekommen. An dem Tag, an dem das nächste Debian-Release erscheint, würde sich nach einem Dist-Upgrade Ihr System von einem sarge zu einem etch verwandeln.
3.2. Sie entscheiden sich für ein Debian-Release

Wenn Sie sich am 01.01.2009 für ein Debian-Release entschieden hätten, dann hätten Sie die Wahl gehabt zwischen:

  • sid: Mit sid bekommen Sie automatisch immer ein unstable.
  • lenny: Am 01.01.2009 hätten Sie mit lenny automatisch ein testing bekommen. An dem Tag, an dem das nächste Debian-Release erscheint, würde sich nach einem Dist-Upgrade Ihr System von einem testing zu einem stable verwandeln. Im Grunde würde bei einem Dist-Upgrade das passieren, was immer bei einem Dist-Upgrade auf einem testing-System passiert: Sie würden (ein letztes mal) die letzten Änderungen an den Paketen und Programmen erhalten.
  • etch: Am 01.01.2009 hätten Sie mit etch automatisch ein stable bekommen. An dem Tag, an dem das nächste Debian-Release erscheint, würde sich nach einem Dist-Upgrade Ihr System von einem stable zu einem oldstable verwandeln. Faktisch würde hier nichts oder nicht viel passieren, weil sich ein Debian-Release vom Typ stable bis auf ein paar Security-Updates nicht mehr entscheidend ändert.
  • sarge: Am 01.01.2009 hätten Sie mit sarge automatisch ein oldstable bekommen. Weil Sie damit rechnen müssen, dass 1 Jahr nach der Verwandlung eines Debian-Releases von stable nach oldstable keine Security-Updates für dieses Debian-Release mehr bereitgestellt werden, würden Sie höchstwahrscheinlich feststellen, dass allenfalls das erste Dist-Upgrade, das Sie durchführen werden, neue Security-Updates auf das System holen werden, sofern diese ohnehin nicht bereits vorhanden sind. Alle weiteren Dist-Upgrades werden an Ihrem System nichts mehr ändern, weil eine Pflege von sarge schlicht nicht mehr stattfindet. An dem Tag, an dem das nächste Debian-Release erscheinen wird, wird sich daher an Ihrem System nur noch ein winziges Detail ändern: Nun wird es auch den Status oldstable verloren haben. Wenn Ihnen das egal ist, können Sie es gern weiterbenutzen, denn funktionieren wird es auch weiterhin noch. Aber es wird mit jeder Sicherheitslücke, die neu entdeckt wird, ein bisschen unsicherer und mit jedem Stück Hardware, das neu erfunden wird, ein bisschen inkompatibler zu aktueller Hardware sein.
3.3. Ihre Entscheidung

Nun kennen Sie die Optionen und ihre Konsequenzen. Überlegen Sie jetzt, was Sie eigentlich wollen:

  • Wenn Sie genau wissen, was Sie tun und immer bei einer bestimmten Debian-Distribution bleiben wollen, unabhängig davon, welches Debian-Release gerade aktuell ist, dann wählen Sie die Debian-Distribution, für die Sie sich entschieden haben.
  • Wenn Sie ein bestimmtes Debian-Release brauchen, Ihnen die tatsächliche Entwicklungsstufe dieses Debian-Releases eigentlich egal ist, und Sie auch nicht täglich auf Veränderungen in der Debian-Welt reagieren wollen oder können, dann nennen Sie das Debian-Release, das Sie sich ausgesucht haben, konsequent beim Namen. Dann wissen Sie immer genau, was Sie haben. Böse Überraschungen bleiben Ihnen dann erspart.

4. Revisionen

Die Debian-Distribution stable ändert sich, wie oben bereits vermerkt, grundsätzlich nicht mehr. Die Ausnahme sind Security-Updates. Weitere Ausnahmen sind Zwischenreleases. Das erste Zwischenrelease in der Geschichte Debians erschien am 26.07.2008 mit dem Namen "EtchAndAHalf".

Ich wiederhole noch einmal, was ich bereits oben geschrieben habe: Wenn Sicherheitslücken entdeckt werden, die sich in stable befinden, dann werden sogenannte Security-Updates für stable erstellt. Diese Security-Updates wandern meistens mit dem nächsten dist-upgrade (von apt-get oder aptitude) auf die Rechner derjenigen Debian-Anwender, die ein stable betreiben. Wenn sich genügend Security-Updates angesammelt haben, dann erscheint eine neue Revision.

Am Beispiel von etch zeige ich Ihnen nun, was das bedeutet:

  • Das Original-Release von etch hat den Namen "Debian Etch, Revision 0". Die genaue Release-Nummer heißt "4.0_r0".
  • Die irgendwann darauf gefolgte Revision hat den Namen "Debian Etch, Revision 1". Die genaue Release-Nummer heißt "4.0_r1".
  • Die irgendwann darauf gefolgte Revision hat den Namen "Debian Etch, Revision 2". Die genaue Release-Nummer heißt "4.0_r2".
  • Die irgendwann darauf gefolgte Revision hat den Namen "Debian Etch, Revision 3". Die genaue Release-Nummer heißt "4.0_r3".
  • Die irgendwann darauf gefolgte Revision hat den Namen "Debian Etch, Revision 4". Die genaue Release-Nummer heißt "4.0_r4".
  • Die kurz darauf gefolgte Revision hat den Namen "Debian Etch, Revision 4a". Die genaue Release-Nummer heißt "4.0_r4a".
  • Die irgendwann darauf gefolgte Revision hat den Namen "Debian Etch, Revision 5". Die genaue Release-Nummer heißt "4.0_r5".
  • Die irgendwann darauf gefolgte Revision hat den Namen "Debian Etch, Revision 6". Die genaue Release-Nummer heißt "4.0_r6".

Mehr muss hierzu nicht erklärt werden. Wenn Sie die ISO-Images des jeweils aktuellen Debian stable herunterladen, heißt das für Sie, dass Sie mit dem Download der ISO-Images die älteren Security-Updates gleich mit bekommen.

4.1. Zwischenreleases

Die Zwischenreleases enthalten neben Security-Updates auch neuere Treiber. Hardware, die erst nach dem Release (Revision 0) des jeweils aktuellen stable auf dem Markt erschienen ist, kann damit besser unterstützt werden (Sie müssen sich dann nicht mehr selbst aufwändig mit Backports herumschlagen).

Ob es sich bei einer Revision um ein Zwischenrelease handelt, ist der Revision nicht anzusehen. Ob ein Zwischenrelease erschienen ist, darüber informieren die Medien.

Das erste Zwischenrelease in der Geschichte Debians mit dem Namen "EtchAndAHalf" befindet sich in Form von zusätzlichen Paketen und ISO-Images in allen Etch-Revisionen ab Revision 4.

Wenn Sie die neuen Hardware-Treiber benötigen, müssen Sie explizit entweder das für die Installation hergestellte ISO-Image herunterladen oder die zusätzlich vorhandenen Pakete installieren.

Wenn Sie die ganz normalen ISO-Images verwenden und auch nur die ganz normalen Pakete installieren (die Pakete, die bis Revision 3 schon vorhanden waren), dann werden Sie das Zwischenrelease gar nicht erst bemerken. Dieses Verhalten ist deshalb so, weil der Anwender sich laut Debian-Philosophie darauf verlassen können muss, dass sich in einem stable nichts bis auf die Security-Updates ändert.

Wenn Sie die zusätzlichen Pakete oder ISO-Images nutzen, dann tun Sie das ausdrücklich (nie aus Versehen), damit Sie neue Hardware nutzen können, und bezahlen dann nur wissentlich (nie aus Versehen) mit dem Preis, dass Sie mit Ihrem jetzigen Handeln den von der ursprünglichen Debian-Philosophie vorgegebenen Weg verlassen.

5. Änderungen seit Lenny

Seitdem Lenny den Status stable erhalten hat, haben sich offenbar Details bei der Notation der Versionen (und Zwischenreleases) geändert.

Der Unterschied zwischen Alt und Neu kann wie folgt verdeutlicht werden:

  • Das Original-Release von etch hat den Namen "Debian Etch, Revision 0". Die genaue Release-Nummer heißt "4.0_r0".
  • Das Original-Release von lenny hat den Namen "Debian 5.0, Revision 0". Die vollständige Release-Nummer heißt "5.0.0".

Damit beobachte ich einen Trend in Öffentlichkeit und Medien, der sich von der Verwendung des Codenamens als Versionsbezeichnung wegbewegt, hin zur Verwendung der ersten beiden Zahlen aus der Release-Nummer (Major-Release + Minor-Release).

6. Mehr Infos

Das hier vorliegende Modul bereitet das Thema der Release-Verwaltung so auf, dass Sie es mit möglichst wenigen Vorkenntnissen verstehen können. Wenn Sie das Modul jetzt bis hierher durchgelesen haben und trotzdem noch Fragen haben, können Sie es entweder noch einmal lesen oder Ihre Recherche auf den weiter unten genannten Seiten fortsetzen.

6.1. Meine wichtigsten Quellen, bevor ich dieses Modul geschrieben hatte

Beim Schreiben dieses Moduls nützten mir zunächst meine Erinnerungen an lebhafte Gespräche mit Debian-Profies in den Jahren 2001 bis 2003. Seit Anfang 2006 befasse ich mich systematisch autodidaktisch mit dem Thema "Debian". Auch die dabei angefallenen Erfahrungen nützten mir beim Schreiben dieses Moduls. Neben Google allgemein bezog ich weitere Informationen hauptsächlich aus diesen Quellen hier:

6.2. Quellen, die mir nach dem Entstehen dieses Moduls in die Hände gefallen sind

Zu diesem Modul gab es einen sehr konstruktiven Dialog zwischen mir und dem Debian-Forum:

Dabei bekannt gewordene zusätzliche Links:

Das hier wäre ein guter Anlaufpunkt, um mehr über die Debian-Release-Verwaltung zu lernen:

7. Anmerkungen

Anmerkungen zu diesem Modul gibt es hier.