© chuyu, 123RF

Dgit verbindet als Zwei-Wege-Gateway das Debian-Archiv mit einem Git-Repository. Das beschert Paketbetreuern ganz neue Möglichkeiten der Softwareverwaltung, verbessert aber auch den allgemeinen Umgang mit Debian-Quellpaketen und dem Archiv.

Versionsverwaltungen sind ein Grundbaustein ambitionierter Software-Entwicklung und kommen vor allem beim kooperativen Entwickeln von Systemen zum Zuge. Viele Programmierer benutzen das vom Linux-Vater Torvalds geschriebene Git [1], mit dem beispielsweise die Kernelentwickler arbeiten. Aber nicht nur die.

Gits Stärke, Revisionen zu verwalten und flexibel Code zu tauschen, machen sich auch Debian-Entwickler zunutze. Das Projekt greift auf verschiedene Weisen auf Git zu. Das bislang noch experimentelle Dpkg-Source-Format 3.0 (git) [2] benutzt zum Beispiel Git-Technik, um einige Schwächen des aktuellen Deb-Src-Standards zu beheben [3].

Hauptsächlich sorgt Git in Debian zurzeit aber für die gemeinschaftliche Paketpflege in einzelnen Entwicklergruppen. So verteilt es zum Beispiel in Debian Science Änderungen unter den Mitgliedern. Meistens kommen dabei die Werkzeuge »git-buildpackage« [4] und »git-dpm« [5] zum Einsatz.

Dgit

Dgit (Abbildung 1, [6]) verfolgt hingegen einen etwas anderen Ansatz: Es dockt für die Arbeit an den Paketquellen direkt an die Debian-Infrastruktur an. Das Tool von Ian Jackson liegt aktuell in Version 1.4 vor. Es handelt sich dabei um ein Zwei-Wege-Gateway, das Debians Archiv in Git überführt und umgekehrt [7]. Das ermöglicht es dem Benutzer, beliebige Quellpakete aus dem Archiv in ein lokales Git-Repository zu laden, anschließend Git-basiert daran zu arbeiten und schließlich die Binärpakete aus dieser Umgebung heraus zu bauen.

Abbildung 1: Das Dgit-Repository. Aktuell ist die Version 1.4.

Paketbetreuer spielen ihre Änderungen darüber hinaus mit Dgit auch wieder ins Debian-Archiv ein. Diese Technik bietet viele neue Möglichkeiten für die Paketpflege, aber auch generell für den Umgang mit dem Debian-Archiv und den darin enthaltenen Quellpaketen.

Klonen

Entwickler installieren Dgit als CLI-Tool. Ein »dgit clone Paketname« zieht dann jedes beliebige Quellpaket aus dem Debian-Archiv (Abbildung 2, [8]). Im Arbeitsverzeichnis landet dann neben dem aktuellen Upstream-Tarball das ausgepackte Quellverzeichnis mit dem Unterordner »debian/« . Der Schritt entspricht dem Aufruf von »apt-get source Paketname« , wobei der Admin hier keine »deb-src« -Paketquelle in der Datei »/etc/apt/sources.list« angeben muss. Nach dem Download mit Dgit fehlen zwar die Registerdatei (».dsc« ) und der Tarball mit den Debian-Dateien (».debian.tar.xz« ), aber das Auspacken des Quellpakets mit »dpkg-source -x« erübrigt sich.

Abbildung 2: Über einen Clone-Befehl lassen sich beliebige Quellpakete aus dem Debian-Archiv ziehen.

Das Quellverzeichnis steht nun schon unter der Kontrolle von Git, was der Debianer mit »git status« nachprüft. Ob jemand das Paket bereits mit Dgit bearbeitet hat oder nicht, verrät der Befehl »git log« .Wenn nicht, erscheint nur ein Commit mit dem Hinweis, das Paket sei aus dem Archiv importiert worden.

Gibt der Nutzer keinen bestimmten Debian-Zweig an (über »dgit PaketnameZweig« ), holt Debian das Quellpaket aus der Entwicklungsversion Unstable. Das lässt sich am Namen des aktuellen Git-Zweiges mit »git branch« überprüfen, im genannten Fall steht dort »dgit/sid« .

Paketpflege

Der Admin pflegt das Paket, indem er Patches schreibt oder die Steuerdateien in »debian/« an Änderungen des Upstream-Codes anpasst. Für die Arbeit im Quellverzeichnis bietet ihm Dgit alle Möglichkeiten von Git. Dadurch kann er Dinge unkompliziert ausprobieren, gespeicherte Änderungssätze ohne Aufwand nachbearbeiten oder verwerfen. Auf Wunsch verwendet der Nutzer beim Entwickeln experimentelle Git-Zweige.

Bei Bedarf wendet der Debian-Verwalter die Tools für Debians Paketpflege in einem Git-Repository an (Abbildung 3). So generiert Debcommit (Paket: »devscripts« ) automatisch Commit-Messages aus Einträgen in »debian/changelog« .

Abbildung 3: Gitk gehört zu den Werkzeugen, mit denen sich Debian-Pakete bearbeiten lassen.

Einige Entwicklergruppen pflegen ihre Pakete ohnehin seit Längerem schon in öffentlichen Git-Repositories. Dabei landet die zugehörige URL im »Vcs-Git« -Feld in der Datei »debian/control« . Dgit richtet das Gruppen-Repository beim Klonen automatisch als weiteres Remote-Repository ein, was zum Eintrag »Remote: vcs-git« in der Datei ».git/config« führt.

Für den Dreiecksaustausch von Code binden Debian-Maintainer das Git-Repository der Entwickler als Remote ein. Andere verwandeln den neuesten Code im Cherry-Picking-Verfahren unkompliziert aus einer lokalen Kopie des Upstream-Repo in Debian-Patches.

Bauen

Will der Paketbetreuer eine neue Paketversion ins Archiv laden oder Binärpakete (».deb« ) erzeugen, baut er diese aus dem Git-Verzeichnis heraus. Dgit bietet Wrapper für verschiedene Bauwerkzeuge wie den Chroot-Builder Sbuild [9]. Existiert bereits ein Unstable-Chroot [10], baut er das neue Quellpaket zusammen mit den Binärpaketen einfach über den Befehl »dgit sbuild« im RAM-Overlay. Dabei sollte er aber Dgit die Cleaning-Option »-wdd« mitgeben, um die Verfügbarkeitsprüfung vor dem Wechsel in die Chroot-Umgebung zu umgehen.

Eine weitere nützliche Voreinstellung von Dgit besteht darin, dass es nach dem Bau automatisch das Werkzeug Mergechanges (Paket: »devscripts« ) anwendet. Das erzeugt aus der entstandenen »_arch.changes« -Datei noch eine weitere, für einen Source-only-Upload geeignete »_multi.changes« -Datei. Dgit bevorzugt diese beim Hochladen, das Buildd-Netzwerk baut dann noch einmal die Binärpakete für die lokal verwendete Architektur neu, was generell empfohlen ist. Damit das richtig funktioniert, muss der Baumeister Dgit aber noch die Option »–mergechanges:-i« mitgeben oder das Tool mit dieser konfigurieren.

Einspielen

Löst der Paketbetreuer den Befehl »dgit push« aus, starten zwei Prozesse: Der Befehl unterschreibt zunächst das erzeugte neue Quellpaket mit seinem GPG-Schlüssel und lädt es anschließend in das Debian-Archiv hoch. Das entspricht dem, was sonst die Werkzeuge Debsign (Paket: »devscripts« ) und Dput (Paket: »dput-ng« ) separat bewerkstelligen. Der Upload findet in Form eines anonymen FTP-Upload auf den Server »ftp.upload.debian.org« statt.

Zweitens taggt er seinen aktuellen Codeschnipsel mit dem Stempel-Format »debian/Paketversion« [11] und gleicht das Dgit-Repository auf dem Alioth-Server von Debian mit dem eigenen Arbeitsverzeichnis ab. Die Git-Historien der mit Dgit bearbeiteten Pakete landen allerdings nicht im Debian-Archiv, denn das ist dafür nicht gemacht. Nach Abschluss des Vorgangs browsen Interessierte stattdessen online in den protokollierten Commits [12].

Klont ein Nutzer ein bereits mit Dgit bearbeitetes Paket erneut oder aktualisiert er ein bereits vorhandenes lokales Repository mit »dgit fetch« , spielt Dgit die auf dem Dgit-Server gespeicherte Git-Historie wieder ein. Um Quellpaket und Git-Repo stets synchron zu halten, gibt es mittlerweile ein spezielles Dgit-Feld für die Kontrolldateien (».dsc« ) im Debian-Archiv, das den Hash des korrespondierenden Git-Commits enthält [13].

Ruft ein Admin »dgit push« ohne Upload- Rechte auf, bricht der Kontakt mit dem Debian-Archiv und dem Dgit-Server wieder ab. In diesem Fall wandelt Dgit aber die aktuellen Commits in Patches um. Er kann sie dann zum Beispiel den Entwicklern zuschicken oder anderen im Bugtracking-System zur Verfügung stellen. Für das Klonen gibt es keinerlei Beschränkungen.

Fortschritt

Relevant ist Dgit zunächst natürlich für Debian-Entwickler. Sie bearbeiten damit beliebige Pakete ad hoc oder wiederkehrend auch außerhalb der Entwicklergruppen in Git. Das betrifft auch gelegentliche Arbeit an Paketen anderer oder ganz ohne festen Betreuer. Gut ist, dass die Software Commit-Historien nicht verwirft, sondern zentral aufbewahrt und online einsehbar macht, denn manche User möchten aus verschiedenen Gründen verfolgen, wie sich ein Paket entwickelt. Dgit eignet sich auch sehr gut für das Paket-Sponsoring: Dabei überprüfen erfahrene Debian-Entwickler die Änderungen von Neueinsteigern vor dem Upload.

Dgit bietet sich auch für Admins an, die lokale Versionen offizieller Debian-Pakete mit speziellen Anpassungen für bestimmte Systeme pflegen. Bisher mussten Entwickler das lokale Patch bei einem Archiv-Update immer wieder in ein neues Quellverzeichnis kopieren, um aktualisierte Binärpakete zu bauen. Mit Dgit zieht der Betreuer neue Versionen des Quellpakets einfach in das Arbeits-Repository und pflegt sie ein, was die lokalen Anpassungen erhält. Von Dgit profitieren nicht zuletzt Downstream-Entwickler, etwa bei der Pflege von Debian-Derivaten. Die Möglichkeiten zur Integration vervielfältigen sich, wenn anstelle eines FTP-Mirror Git-Repositories vom Debian-Archiv bereitstehen.

Fazit

Dgit bietet gegenüber herkömmlichen Verfahren zum Umgang mit Debian-Quellpaketen und dem Archiv eine ganze Reihe von Vorteilen für diverse Anwendungsprofile. Es modernisiert den Zugriff auf das Debian-Archiv auf einfallsreiche Weise und erweist sich als stabil und ausgereift.

Dennoch bleibt abzuwarten, ob sich Dgit unter den Debian-Entwicklern auf breiter Front durchsetzen wird und ob Pakete in nennenswerter Anzahl auf dem Dgit-Server auftauchen. Denn prinzipiell ist Dgit zwar offen für die Integration in bereits existierende Git-Workflows der Debian-Entwicklergruppen, allerdings erweist sich der dafür zu betreibende Aufwand mitunter als höher als der dadurch erreichbare Mehrwert. So muss der Benutzer zum Beispiel spezielle Zweige einrichten, um die verwendeten Upstream-Tarbälle im Dgit-Repositorium aufzubewahren.

Andererseits entpuppt sich Dgit für das Paketarchiv als nützliches und womöglich zukunftsweisendes Zusatzfeature, weshalb es längerfristig nicht nur in dem kleinen Kreis von Debian-Entwicklern auf Interesse stoßen dürfte. Seine Stärken spielt Dgit auch ohne Fokus auf den kollaborativen Aspekt aus und lässt sich für reine Nur-Lesen-Zugriffe auf das Archiv einspannen. Zum Beispiel setzt Ubuntu Dgit mittlerweile auf diese Weise ein [14].

Hinzu kommen noch die ausgeklügelten Möglichkeiten, um Änderungen an bearbeiteten Paketen auszutauschen. Sie stellen Dgit mit seinem separaten Workflow alternativ neben die Werkzeuge »git-buildpackage« und »git-dpm« [15].