Der Lebenszyklus von Debian-Paketen
Von Apstream bis zukunftssicher
Chemnitzer Linux-Tage 2006
5 März 2006
Übersicht
- Struktur von Debian-Paketen
- Der Weg eines Paketes in das Archiv
- Der Weg durch das Archiv
- Security-Updates, externe Quellen und Versionsnummern
Was sind Debian-Pakete?
- Debian-Pakete sind entweder
- Quellpakete (source packages, .orig.tar.gz/.diff.gz)
- Binärpakete (binary packages, .deb)
- Im Debian-Archiv befinden sich zur Zeit an die
- 10'000 Quellpakete
- 16'000 Binärpakete
- Debian-Pakete werden mit Metadaten beschrieben, u.a.:
- zuständiger Entwickler (Maintainer)
- Priorität
- Versionsnummer
Quellpakete
Quellpakete bestehen aus 2-3 Dateien:
- Original-Software in tar-Archiv
- Eventuell vorhandene diff.gz-Datei "debianisiert"
- dsc-Datei beschreibt das Paket
Zum Beispiel:
ipcalc_0.40-1.diff.gz 13-Jul-2005 12:32 5k ipcalc_0.40-1.dsc 13-Jul-2005 12:32 1k ipcalc_0.40.orig.tar.gz 13-Jul-2005 12:32 21k
Binärpakete
Ein Binärpaket besteht genau aus einer DEB-Datei
Ein Binärpaket wird aus einem Quellpaket generiert
Jedes Quellpaket generiert mindestens ein Binärpaket, pro Quellpaket mehrere Binärpakete möglich:
* apache2-common_2.0.55-4_i386.deb 16-Jan-2006 13:32 787 apache2_2.0.55-4.diff.gz 16-Jan-2006 13:32 113k apache2_2.0.55-4.dsc 16-Jan-2006 13:32 1k * apache2_2.0.55-4_i386.deb 16-Jan-2006 13:32 35k apache2_2.0.55.orig.tar.gz 23-Oct-2005 03:47 5.8M * libapr0_2.0.55-4_i386.deb 16-Jan-2006 13:32 134k
Abhängigkeiten und Konflikte
- Binärpakete können von einander abhängen
- Eine Abhängigkeit kann sich auf ein anderes Paket, oder spezielle Versionen des anderen Paketes beziehen
- Pakete können auch zueinander im Konflikt stehen (auch hier sind Versionsangaben möglich)
Der Paketzyklus
Graphik aus dem Buch Das Debian-System.
dak
"katie und Ihre Freundinnen"
- Skriptsammlung zur Verwaltung des Debian-Archivs
- Skripte benannt nach Vornamen von Schauspielerinnen
- dak liegt auf cvs.debian.org
Anmerkung: Ich kenne mich mit dak noch nicht wirklich aus
Der Weg in das Archiv (1)
- Verständnis der Software
- Debianisierung
- Automatische Tests (lintian, linda, piuparts, ...)
- Funktionstest, evtl. Peer Review
- Upload in die UploadQueue
- queued übergibt Pakete an jennifer (Incoming)
Der Weg in das Archiv (2)
- jennifer überprüft und verteilt in eins von vier Verzeichnissen:
- accepted -- das Paket wurde akzeptiert (http://incoming.debian.org)
- rejected -- das Paket wird auf Grund von Fehlern nicht angenommen
- NEW -- das Paket ist neu und bedarf deshalb manueller Zustimmung
- BYHAND -- das Paket bedarf manueller Zustimmung
- dinstall engagiert kelly um Pakete nach unstable zu installieren.
jennifer
jennifer überprüft, ob:
- Pakete konsistent und vollständig sind
- Die Binärpakete bereits im Archiv existieren
- Wenn ja, ob die neue Versionsnummer höher ist als existierende
- Der Upload von einem Debian Entwickler signiert wurde
Die NEW-Queue
- Binärpakete, von denen noch keine Version im Archiv existiert müssen wegen Qualitätssicherung und US-Exportkontrolle von Hand genehmigt werden
- Dies betrifft komplett neue Pakete, wie auch Quellpakete, die ein zusätzliches Binärpaket einführen
- Jörg ist (einer) unser(er) Kerberos, sein Vortrag ist im Anschluss: "Tausend Wege sein Paket durch die NEW-Queue zu schmuggeln"
Build-Daemons
- Debian umfasst 12 Architekturen
- Für jede Architektur gibt es mindestens einen Build-Daemon
- Build-Daemons haben Zugang zu accepted und unstable
- Aus accepted wird jedes Paket gebaut
- Aus unstable werden nur die Pakete erstellt, die für die jeweilige Architektur noch nicht erstellt wurden
- Nach dem Bauen muss das Paket vom Administrator abgesegnet werden
- Hierauf wird es regulär in die UploadQueue geladen
debian/changelog
Jedes Paket muss eine changelog Datei beinhalten
Diese Datei dient als zentrale Quelle für Informationen zum Upload
Für jede Debian-Version existiert ein Eintrag wie folgt:
gmrun (0.9.1-2) unstable; urgency=low * Enhance default /etc/gmrunrc an new URL handler; URL_term which launches the given command with 'sh -c', in an x-terminal-emulator, and waits for input when the command finishes. (Thanks to martin f krafft <madduck@debian.org> for the initial patch.) * [...] -- David B. Harris <dbharris@debian.org> Sun, 19 Feb 2006 13:20:04 -0500
Die erste Zeile des changelog
gmrun (0.9.1-2) unstable; urgency=low
Diese Zeile setzt sich zusammen aus
- Paketname
- Version
- Zielarchiv
- Dringlichkeit
Die changes-Datei (1)
Diese Datei wird u.a. aus dem changelog generiert:
Date: Sun, 19 Feb 2006 13:20:04 -0500 Source: gmrun Architecture: source i386 Version: 0.9.1-2 Distribution: unstable Urgency: low Maintainer: David B. Harris <dbharris@debian.org> Changes: gmrun (0.9.1-2) unstable; urgency=low . * Enhance default /etc/gmrunrc an new URL [...] * [...] Files: 7323b4ac1cf2d0899f864f4d5204dd1e 866 x11 optional gmrun_0.9.1-2.dsc 3457ad0cb1622b1453193ab76784fe96 28335 x11 optional gmrun_0.9.1-2.diff.gz be1748b798cbe258d717e029cf9f0650 46126 x11 optional gmrun_0.9.1-2_i386.deb
Die changes-Datei (2)
- Die Datei listet Dateien, die zum hochzuladenden Paket gehören
- Sie steuert den Prozess:
- Version: 0.9.1-2 -- ein Paket kann nur ältere Versionen ersetzen
- Distribution: unstable -- das Paket wird von dinstall nach unstable geladen (nicht z.B. experimental)
- Urgency: low -- es herrscht keine Dringlichkeit
Vertrauenspfad und Paketintegrität
- Hochgeladene Pakete müssen von einem Entwickler signiert sein
- D.h. Paketintegrität ist bis Incoming gewährleistet
- Das eigentliche Archiv ist nicht zugänglich, es können also praktisch keine Pakete hineingeschmuggelt oder geändert werden.
- Vertrauensprobleme bei Mirrors
Der Weg von unstable zu stable (1)
- Das Debian-Archiv besteht aus drei Hauptteilen:
- unstable
- testing
- stable
- Zusätzlich gibt es noch drei Teile, die intern genutzt werden:
- experimental
- testing-proposed-updates
- stable-proposed-updates
- Das oldstable-Archiv enthält das vorherige Release (hauptsächlich wegen der Security Updates)
Der Weg von unstable zu stable (2)
- Es gibt keine automatische Migration von experimental zu unstable, d.h. das Paket muss erneut hochgeladen werden (mit höherer Versionsnummer) mit unstable als Zielarchiv in der changelog-Datei
Migration nach testing
Ein Paket migriert von unstable (sid) zu testing (etch) wenn folgenden Konditionen erfüllt sind:
- Das Paket hat die Minimalzeit in unstable überstanden
- Das Paket steht in der Version für alle Architekturen bereit
- Das Paket führt nicht zu Konflikten in testing
- Alle Abhängigkeiten des Paketes können mit Paketen aus testing erfüllt werden
- Die Version des Paketes hat nicht mehr RC-Fehler als die jetzige Version in testing (falls vorhanden)
- Das Paket nicht eingefroren wurde
Mit Hilfe von testing-proposed-updates können diese Konditionen im Sonderfall übergangen werden.
Dringlichkeiten von neuen Versionen
- In der changelog-Datei wird die Dringlichkeit (urgency) einer neuen Paketversion angegeben
- Diese steuert die Minimalzeit, die ein Paket in unstable verweilen muss:
- low -- 10 Tage
- medium -- 5 Tage
- high -- 2 Tage
- urgent -- 1 Tag
- Es kann bis zu einem Tag länger dauern da Pakete nur einmal am Tag in das Archiv geschoben werden (und Mirrors nur einmal täglich synchronisieren)
Freeze: testing wird stable
- Im Vorlauf zu einem neuen Release werden Pakete in testing eingefroren:
- zuerst Pakete mit Priorität required und important. Dies erlaubt abhängigen Paketen, sich zu stabilisieren
- danach standard, und zuletzt optional und extra
- RC-Bugs dürfen auch bei eingefrorenen Paketen repariert werden
- Wenn alle Pakete eingefroren wurden steht dem Release nichts mehr im Weg
- Zu guter Letzt werden die Symlinks umgebogen. Bald z.B.:
- oldstable -- von woody auf sarge
- stable -- von sarge auf etch
- testing -- von etch auf <noch unbekannt>
Der Weg durch das Archiv
- Jedes der drei Archive kann eine eigene Version jedes Paketes enthalten, sie sind voneinander unabhängig
- Einzelne Versionen können in mehreren Archiven vorhanden sein
- In jedem Archiv kann eine Version eines Paketes nur durch eine strikt neuere Version ersetzt werden
Anatomie des Archivs (1)
Im Archiv herrscht strikte Trennung von Paketsammlungen nach Freiheitsgrad:
- main -- das Hauptarchiv
- contrib -- Freie Software, die von unfreier Software abhängt
- non-free -- Unfreie Software
Das Debian-Archiv besteht hauptsächlich aus zwei Hierarchien:
dists -- enthält die Paketindices, nach Release, Sammlung und Architektur sortiert:
/dists/stable/main/binary-i386/Packages /dists/stable/main/source/Sources
pool -- beinhaltet die eigentlichen Pakete, nach Sammlung und Quellpaketname sortiert:
/pool/main/a/apache2/apache2-common_2.0.55-4_i386.deb
Anatomie des Archivs (2)
Graphik aus dem Buch Das Debian-System.
Security Updates und "stable-dot-releases"
- Das Debian Security Team stellt unter security.debian.org ein separates Archiv mit Sicherheitsaktualisierungen bereit.
- Wenn in einem Paket ein Problem behoben wird, wird es sowohl in das Security-Archiv geladen, als auch nach stable-proposed-updates
- In regelmäßigen Abständen wird stable-proposed-updates mit stable zusammengeführt. Dies nennt man "stable-dot-release" oder "r-release" (z.B. "Debian sarge 3.1r1"
Externe Quellen und Versionierung
- Bestimmte externe Quellen existieren, um ein Archiv zu erweitern; z.B. für
stable:
- Sicherheits-Archiv
- Volatile-Archiv
- Backports.org
- Debian Unofficial
- Pakete darin obligen strengen Kriterien
- Spezielle Versionsnummern, die sich genau zwischen stable und
testing einordnen. Z.B. apache:
- 1.3.33-6 in sarge 3.1r0a
- 1.3.33-6sarge1 im Security-Archiv und sarge 3.1r1
- 1.3.34-2 in testing
Stärken des Archiv-Prozesses
- Fast vollständig automatisiert
- Dennoch flexibel
- Skalierbar
- Reife
- Autonom und schwer "kaputtzukriegen"
Schwächen des momentanen Archiv-Prozesses
- Pakete werden nicht auf der heraufgeladenen Architektur neu gebaut
- Pakete müssen einzeln manuell vom Build-Daemon-Administrator signiert werden
- Bisweilen schwierig, in das Archiv einzugreifen
- Zentral, Single Point of Failure
Aussicht in die Zukunft
- Mirror-Split
- Archivsignaturen
- Kleine Änderungen, sonst zufrieden
Das Buch
"608 pages pure Debian"
Martin F. Krafft: The Debian System (3-937514-07-4)
Seit gestern auch in deutscher Fassung (651 Seiten):
Martin F. Krafft: Das Debian-System (3-937514-17-1)
Webseite: http://debiansystem.info
Ich beantworte Ihre Fragen gerne heute um 12:30 Uhr am Open Source Press Stand gleich beim Eingang (E13)
Licence
These slides, their design, and the content are © Martin F. Krafft and released under the terms of the Artistic Licence.
reStructuredText sources: slides.rst and ui/debian/*