Unter einem Backport versteht man im allgemeinen eine Package, die unter Debian stable aus Sourcen gebaut wurde, die aus Debian unstable entnommen wurden. Dies ist dann notwendig, wenn man neuere Software für ein stable-System benötigt, aber weder die Distribution noch auf einen der Entwicklungs-Zweige von Debian wechseln möchte.

Dieses Dokument soll den Weg zu funktionierenden Backports beschreiben und setzt Vertrautheit mit dem Bau von Debian-Packages. Es behandelt die Dinge, die man beim Backporten im Vergleich zum Bau einer Package unter der “passenden” Debian-Distribution beachten muss.

Wenn apt eine neue Package installiert, entscheidet es anhand der Versionsnummern und der lokalen Pinning-Informationen, welche der verfügbaren Versionen der Package installiert wird. apt-cache policy [package] gibt einen Einblick in die Arbeitsweise.

Dieser Abschnitt beschreibt die Vergabe von Versionsnummern an Packages innerhalb nichtöffentlicher Backport-Distributionen.

Designziele:

• Eine lokale Package von foo soll die alte stable-Version von foo ersetzen
• Bei Freigabe einer neuen stable Distribution sollen:
  • neue stable-Versionen lokale Backports ersetzen
  • lokal veränderte Packages sollen aber unverändert bleiben
• lokale Packages sollen in einer Packageliste auf den ersten Blick als solche erkennbar sein.

Die Versionsnummern sollten also:

• Größer als die Version in Stable sein
• Kleiner als die Version in Unstable sein
• einen Kennzeichenstring enthalten.

Die Versionsnummern von Debian-Packages bestehen im allgemeinen aus Upstream-Version und Debian-Revision, die mit einem Bindestrich voneinander getrennt werden. So bezeichnet die Nummer 4.24-3 die dritte Debian-Revision des Programms, das der Original-Autor mit der Version 4.24 freigegeben hat.

Eine besondere Rolle spielt (ab Debian sarge) die Tilde ~ in einer Versionsnummer: Die Tilde verkleinert den vor ihr stehenden Wert, so dass [a].[b].[c]~[d] _kleiner_ ist als [a].[b].[c]. Diese Eigenschaft verwenden wir zur Erstellung von Versionsnummern. Bis einschließlich Debian woody hatte die Tilde noch keine Sonderfunktion, was komplexere Verfahren zur Bildung von Versionsnummern notwendig machte. Die sind heute glücklicherweise nicht mehr notwendig. Aufgrund der hohen Komplexität dieser Verfahren dokumentiere ich sie hier auch nicht, da sie mehr Verwirrung stiften als Klarheit schaffen.

Den Versionsnummernmechanismus erweitern wir durch kreativen Umgang mit der Debian Revision. Wer sich für die Innereien interessiert, ziehe die Originaldokumentation zu Rate.

Gesetzt den Fall, es wird ein Backport der Package foo notwendig, die mit der Version [A].[B]-[C] (1.2-3) im unstable-Archiv ist. Die neue Versionsnummer [A].[B]-[C]~z.bpo.1 (1.2-3~z.bpo.1) erfüllt die Anforderungen, da sie

• eindeutig als Backport von [A].[B]-[C] (1.2-3) erkennbar und
• kleiner als [A].[B]-[C] (1.2-3), aber größer als alle vorherigen Versionsnummern ist, inklusive 1.2-3~beta1 oder 1.2-3~rc1 and ähnliches.

Somit ist sichergestellt, dass die neue Package die auf den Systemen bereits vorhandene Package ersetzt:

• Wäre [A].[B]-[C] (1.2-3) in Debian stable, müssten wir keine Backports machen.
• Somit ist [A].[B]-[C-1] (1.2-2), [A].[B]-[C]~beta[D] (1.2-3~beta1) oder [A].[B]-[C]~rc[D] (1.2-3~rc1) die höchste Version die normalerweise in Stable zu finden sein kann. Da [A].[B]-[C]~z.bpo.1 (1.2-3~z.bpo.1) größer als diese ist, ist das gewünschte Verhalten erreicht.

Da [A].[B]-[C]~z.bpo-1 (1.2-3~z.bpo.1) kleiner ist als [A].[B]-[C] (1.2-3), ist ebenfalls sichergestellt, dass bei Freigabe einer neuen Distribution Debian stable die neue stabile Version auch dann unseren Backport überschreibt.

Muss eine zurückportierte und bereits verteilte Package verändert werden (z.B. bei Veränderungen der Standardkonfiguration), so erhält die neue lokale Version die Versionsnummer [A].[B]-[C]~z.bpo.2 (1.2-3~z.bpo.2) usf.

Bei Debian Native Packages wird - ganz analog - aus [A].[B] (1.23) die neue Version [A].[B]~z.bpo.1 (1.23~z.bpo.1).

Beispiele

Die letzten beiden, sehr unübersichtlichen Nummern kommen in der Praxis kaum vor. Wenn Fälle auftreten, die sich aus den hier genannten Beispielen nicht deduzieren lassen - bitte Nachricht hier.

Wenn eine zurückportierte Package lokal so verändert wurde, dass ihre Funktion erheblich von der Debian-Package abweicht, so dass ein automatisches Überschreiben durch neue Debian-Packages nicht gewünscht ist, so muss ein Epoch verwendet werden. Da dies aber weitreichende Folgen haben kann, würde eine ausführliche Erörterung den Rahmen dieses Dokumentes sprengen. In manchen Situationen ist es in diesem Fall sinnvoller, die Package umzubenennen.

Soll foo automatisch durch foo-local ersetzt werden, sind Dependency-Tricks notwendig, deren Dokumentation hier noch fehlt.

Es ist sinnvoll, den Bau von Backports in einer Systemumgebung vorzunehmen, die der späteren Betriebsumgebung ähnlich ist. Aus diesem Grund ist es am besten, Backports in einem chroot zu bauen, das auf denselben Stand wie die Zielsysteme (inklusive ebenfalls zurückportierter Packages) ist.

Sourcen für Backport-Packages sollte man - mit wenigen Ausnahmen - grundsätzlich aus Debian unstable nehmen, da es für die testing-Distribution keine zeitnahen Sicherheitsupdates gibt und man sonst Gefahr läuft, eine fehlerhafte Package als Grundlage zu verwenden.

In Freeze-Situationen kurz vor dem Release einer neuen Debian-Distribution ist es eventuell sinnvoll, Sourcen für Backport-Packages doch aus testing zu nehmen, da man dann nach dem Release auf den Backport verzichten kann.

Um eine Package bauen zu können, ist es nicht selten notwendig, dass andere Packages zum Bauzeitpunkt auf dem System installiert sein müssen. Um das automatische Bauen von Packages zu erleichtern, schreibt die Debian-Policy vor, dass Maintainer dokumentieren, welche Packages zum Bauzeitpunkt vorhanden sein müssen. Dies wird als “Build Dependencies” bezeichnet und ist auch für die Herstellung von Backports sehr praktisch.

Build Dependencies werden in der Source-Package in der Datei debian/control in den Feldern “Build-Depends:” und “Build-Depends-Indep:” dokumentiert.

dpkg-checkbuilddeps zeigt eine Liste der nicht zufriedengestellten Build Dependencies.

Baut eine Package trotz installierter Build-Dependencies nicht, so ist das ein Bug in der Source Package, der als solcher an den Debian-Maintainer gemeldet werden sollte. Meist fehlen Packages in Build Dependencies und/oder die Versionierung der Build Dependency.

Ist eine Package, für die die zu bauende Package eine Build Dependency erklärt, in Debian stable nicht enthalten, so muß für diese Package ebenfalls ein Backport erstellt werden. Das kann sich bei komplexeren Packages über mehrere Ebenen fortsetzen und recht arbeitsintensiv sein. So ist es in solchen Fällen eventuell einfacher, zu prüfen, ob die Package nicht auch mit einer älteren Version der gewünschten Package oder gar ganz ohne sie erfolgreich baubar ist.

Derzeit, knapp drei Monate nach dem Release von Debian sarge, ist die Erstellung von Backports vergleichweise schmerzfrei möglich. Je weiter sich Debian unstable von Debian stable entfernt, desto schwieriger wird das Erstellen von Backports wegen nicht mehr in stable vorhandener Build Dependencies. Im folgenden werde ich zu gegebener Zeit dokumentieren, wie man um die gängigen Probleme herumnavigiert.

Im Augenblick sind keine solchen Herausforderungen bekannt.