Spätestens seit Gentoo ist es in Mode, Linux und die dazugehörigen Programme in Eigenregie zu bauen. Conary treibt das Konzept auf die Spitze.

Bereits seit 2004 arbeiten einige Entwickler der Firma rPath, die früher bei Red Hat für das Paketformat RPM zuständig waren, an der nächsten Generation der Paketverwaltung. Das Ergebnis dieser Bemühungen, Conary [1], findet in rPath Linux sowie Foresight Linux ([2], siehe Kasten “Fortschrittliche Distributionen”) Verwendung. Verglichen mit den auf dem Markt vorherrschenden Systemen von Red Hat, Novell und Debian erhalten nicht nur die Pakete selbst eine Versionsnummer.

Conary geht sogar soweit, den darin enthaltenen Dateien eine Revision, ähnlich wie bei CVS/SVN (siehe Kasten “Versionsverwaltung”), zu spendieren. Damit löst Conary viele Probleme, die es bei APT und RPM derzeit gibt. Als weiterer Vorteil kommt hinzu, dass das System nur noch das herunterlädt, was sich auch wirklich geändert hat. Vor allem Benutzern, die kein DSL zu Hause haben, kommt diese Eigenschaft sehr entgegen. Zudem erbt Conary auch das merge, commit, diff und viele weitere, von CVS/SVN bekannte Befehle, die eine Paketrevisionierung erst zulassen.

Abbildung 1: Foresight Linux nutzt als Paketverwaltungssystem Conary und ist auch sonst stets auf dem neuesten Stand.

Begriffserklärung

Conary führt eine Reihe neuer Konzepte und – damit einhergehend – neuer Begriffsdefinitionen ein. Ein Repository im Sinn von Conary Ist eine Datenbank, die Dateien und Pakete enthält (Abbildung 2). Dabei lassen sich sogar mehrere Versionen der Pakete speichern. Alles, was Sie einmal zum Repository hinzugefügt haben, bleibt für immer gespeichert. Das ermöglicht, auch auf ältere Versionen eines Programmpaketes zurückzugreifen. Conary macht davon regen Gebrauch.

Abbildung 2: Ein Beispiel für ein auf dem Rbuilder-Server lagerndes Conary-Repository, hier das jenige von Gdesklets.

Alles, was in einem Repository vorhanden ist, heißt generell Trove. Ein Trove enthält entweder Dateien oder andere Troves. Als Files bezeichnet Conary Dateien mit eindeutigen Bezeichnern. Dies ist ein weiteres Konzept, das sich von den etablierten Paketmanagern unterscheidet. Conary greift mit Hilfe dieser Bezeichner auf die Dateien zu, anstatt Pfadnamen zu verwenden.

Dateien gruppiert Conary in Components und diese wiederum in Packages. Nicht alle Komponenten bilden einen Teil eines Pakets – beispielsweise solche, die auf source oder test enden. Gängige Komponenten sind: doc, lib, runtime oder python. Als Group definiert Conary eine Ansammlung von Troves. Groups tragen grundsätzlich group- in ihrem Namen. Ein Fileset (fileset-) ist analog dazu eine Ansammlung von Dateien.

Von Gentoo wissen Sie vielleicht schon, dass Sie Programme mit verschiedenen Optionen übersetzen können. Das Conary-Äquivalent dazu sind Flavors, wovon es vier zu unterscheiden gilt: architektur-, instruktionssatz- und paketspezifische sowie systemweite Flavors. Changesets repräsentieren Änderungen zwischen zwei Versionen oder stellen ein eigenständiges Paket dar, falls es zuvor keine Version davon gab. Conary verwendet Changesets als Kommunikationsschnittstelle zwischen Client und dem Repository.

Die Versionsnummern fallen bei Conary etwas komplizierter aus als bei Debian oder Fedora: Der Paketname, das Repository, das Label und die Version selbst trennt ein Schrägstrich (“/”) voneinander. Das Bash-Paket heißt beispielsweise

bash=/conary.rpath.com@rpl:devel//1/3.0.16-7-0.1

Im hinteren Teil erkennen Sie die Version. rpl:devel bedeutet, dass es sich um ein mehr oder weniger experimentelles Paket handelt. Ähnlich wie bei Debian durchläuft es dann mehrere Schritte, wie etwa qa für Qualitätssicherung und release für das stabile endgültige Produkt.

Erste Schritte

Falls Sie bereits mit Yum oder Apt gearbeitet haben, bereiten Ihnen die grundlegenden Conary-Optionen keine Probleme. Sie geben sich teilweise sogar intuitiver, wodurch sich die Einarbeitungszeit erheblich reduziert. Bislang steht noch kein grafisches Frontend für Conary bereit, und so müssen Sie vorerst mit der Befehlszeile vorlieb nehmen. Für alle folgenden Operationen benötigen Sie Administratorrechte (sudo su -) und müssen die Groß-/Kleinschreibung bei Paketnamen beachten:

• conary updateall: Aktualisiert das gesamte System
• conary update Paket: installiert Paket
• conary erase Paket: löscht Paket
• conary query: Gibt die Liste der installierten Pakete aus
• conary repquery Paket: sucht im Repository nach Paket

Mit diesen fünf Befehlen haben Sie das System bestens im Griff. Einen guten Überblick über alle Optionen erhalten Sie mit conary help. Interessant ist die Möglichkeit, auf eine ältere Version eines Pakets zu deaktualisieren. Durch die im Paketmanager verwendete Versionierung spielt das System auch hier nur die notwendigen Dateien ein. Auch das Halten von Paketen beherrscht Conary. Speziell beim Linux Kernel erweist sich das manchmal als Vorteil. Sie erreichen das mit conary pin Paket. Um das Paket wieder freizugeben, dient der Befehl conary unpin Paket.

Debian-Benutzer wissen, dass apt-get source Paket aus Quellpaketen, die in einem Apt-Repository liegen, fertige Binärpakete baut. Mit Conary erreichen Sie das durch conary emerge Paket. Über Sinn und Zweck dieser von Gentoo bestens bekannten Aktion lässt sich trefflich streiten: In der Regel brauchen Sie keine Pakete auf diese Weise zu übersetzen.

Fein justiert

Gentoo hat es vorgemacht: Mit Hilfe von so genannten USE-Flags übersetzt das System Programme mit vorgegebenen Optionen. Wenn Sie zum Beispiel Evince ohne Gnome-Abhängigkeiten installieren wollen, sorgt eine spezielle Konfigurationsoption dafür. Die Entwickler von Conary griffen dieses Konzept auf und erweiterten es stark. Unter /etc/conary/ finden Sie eine Reihe von Verzeichnissen und Dateien, in denen Sie allerlei Einstellungen vornehmen können. Die Beschreibung der dortigen Konfigurationsmöglichkeiten ist hier aus Platzgründen nicht möglich. Das Conary-Wiki [1] enthält mehr Informationen dazu, alternativ konsultieren Sie die Conary-Manpage.

Für den Anwender ist die wichtigste Datei wohl /etc/conaryrc. Beachten Sie, dass eine Home-Verzeichnis befindliche Datei .conaryrc (Abbildung 3) die globale Konfiguration überschreibt. Die wichtigsten Schlüsselwörter finden Sie in der Tabelle “/etc/conaryrc“.

.conaryrc aus.” width=”300″ height=”89″ /> Abbildung 3: So kompakt fällt die Konfigurationsdatei .conaryrc aus.

Die meisten Optionen fallen relativ selbsterklärend aus, zumindest zwei bedürfen der näheren Erläuterung: resolveLevel regelt das Auflösen von Abhängigkeiten. Sobald Sie ein neues Paket installieren, versucht Conary die notwendigen Dependencies aufzulösen. Standardmäßig installiert Conary neue Pakete, um den Anforderungen gerecht zu werden. Das System unterstützt aber auch ein anderes Szenario: Falls Paket A das Paket B benötigt, das aber mit Paket C kollidiert, versucht Conary vorab, erst einmal das Paket C zu aktualisieren. Wünschen Sie dieses Verhalten, dann geben Sie resolveLevel 2 an.

Zudem ist es für Conary wichtig zu wissen, wohin es fertige Pakete laden soll. Sie greifen dem Paketmanager mittels des Schlüsselworts user mit einem Tripel aus Hostname, Benutzername und Benutzerpasswort unter die Arme, beispielsweise user *.rpath.org b_nutzer geheim.

Pakete selbst bauen

In der letzten Ausgabe der LinuxUser stellten wir Foresight Linux vor [3]. Die Distribution bietet eine perfekte Grundlage zum Erstellen von Paketen mit Conary. Selbstverständlich können Sie auch auf rPath Linux [6] ausweichen. Verglichen mit anderen Distributionen, fällt das Bauen von Paketen mit einer auf Conary basierenden Distribution wesentlich leichter: Zunächst legen Sie ein neues Konto auf der rPath-Seite [7] an. Das ist notwendig, um Ihre Pakete auf den Server zu laden. Alternativ besteht auch die Möglichkeit ein lokales Repository zu verwenden – falls Sie das wünschen, lesen Sie sich die Wiki Seite [8] durch. Wollen Sie hingegen gleich eine ganze Appliance (siehe Kasten “Software-Appliance”) bauen, bietet das entsprechende rPath-Tutorial [9] einen hilfreichen Anlaufpunkt.

Das frisch installierte Foresight Linux enthält noch nicht die notwendigen Programme, um neue Pakete zu erstellen. Der Befehl conary update conary-build group-devel holt die entsprechenden Komponenten auf den Rechner. Stellen Sie außerdem sicher, dass sich alle Bestandteile von conary-build – vor allem python und runtime – auf dem System befinden. Hat alles geklappt, steht cvc (kurz für “Conary Version Control”) für die Erstellung von Paketen bereit.

Im nächsten Schritt erstellen Sie die Verzeichnisstruktur, die Conary im weiteren Verlauf benötigt: Mit mkdir -p conary conary/builds conary/cache conary/Testprojekt legen Sie die notwendige Struktur an. Dabei speichert Conary unter builds Informationen zum Übersetzungs- und Paketerstellungsvorgang. Eine Protokolldatei darf dabei auch nicht fehlen. Diese bildet später dann einen Teil der debuginfo-Komponente und hilft zur Fehleranalyse. cache speichert das heruntergeladene Archiv, was den Vorteil hat, dass beim erneuten Übersetzen des gleichen Pakets die Datenleitung geschont wird. Unter Testprojekt legt Conary später das fertig erstellte Paket ab.

Falls noch nicht geschehen, erstellen Sie jetzt die Datei .conaryrc (Abbildung 3) in Ihrem persönlichen Verzeichnis. Sie ist für den Build-Vorgang von entscheidender Wichtigkeit (Listing 1). Die beiden Schlüsselwörter buildLabel und installLabelPath legen dabei das Erstellungs-Label und den Server sowie Pfad fest, wohin Sie das Paket später übergeben (“committen”). Bei [Testprojekt] handelt es sich um den Namen, das Projekt erhält. Es darf sich in der Schreibweise nicht von dem vorher erstellten Testprojekt-Verzeichnis unterscheiden. Falls Sie nicht wünschen, dass Conary den Inhalt des Build-Verzeichnisses jedes Mal löscht, fügen Sie vor [Testprojekt] die Zeile cleanAfterCook False ein.

contact          E-Mail-Adresse
name             Benutzername
user             *.rpath.org rBuilder-Online-BenutzernamerBuilder-Online-Passwort
[Testprojekt]
buildLabel       Testprojekt.rpath.org@rpl:devel
installLabelPath Testprojekt.rpath.org@rpl:1 Testprojekt.rpath.org@rpl:devel conary.rpath.com@rpl:1

Conary benötigt noch einen so genannten Kontext, um herauszufinden, welches Repository es gerade vor sich hat. Gehen Sie dazu ins Verzeichnis Testprojekt und erstellen Sie einen neuen Kontext:

$ cd conary/testprojekt && cvc context Testprojekt

Der cvc-Befehl erzeugt die Datei CONARY, die alle notwendigen Informationen für den weiteren Verlauf enthält.

Pakete rezeptpflichtig schnüren

Analog zum Kontext erstellen Sie im Anschluss durch den Befehl cvc newpkg Testpaket ein neues Verzeichnis, das wiederum eine CONARY-Datei enthält. Im Verzeichnis Testpaket erwartet die Paketverwaltung ein Rezept, anhand dessen Conary das Paket schnürt. Mit dem Editor Ihrer Wahl bearbeiten Sie jetzt Testpaket.recipe. Es stehen eine Vielzahl von fertigen Rezepten [10] zur Verfügung. Die meisten Autoren setzen auf die Autotools, passend dazu gibt es das AutopackageRecipe (Abbildung 4).

AutoPackageRecipe kochen Sie im Handumdrehen ein schmackhaftes Conary-Paket.” width=”300″ height=”116″ /> Abbildung 4: Mit dem AutoPackageRecipe kochen Sie im Handumdrehen ein schmackhaftes Conary-Paket.

Ein Beispiel für eine typische Rezept-Datei finden Sie im Kasten “Ein typisches Conary-Rezept”. Sie sehen, dass es sich eigentlich um Python-Quelltext handelt, den Sie aber selbst ohne Vorwissen meistern können. Bei %(name)s und %(upstreamVersion)s handelt es sich um Makros, die denen in den von RPM bekannten spec-Dateien ähneln. Unter [11] finden Sie eine Übersicht aller in Conary vorhandenen Makros. buildRequires ist anfangs noch eine leere Liste, die Sie später noch füllen müssen. Wichtig ist die Einrückung, die bei Python Teil der Syntax ist. Halten Sie sich nicht daran, melden Cvc beziehungsweise Python einen Syntaxfehler.

class Testpaket(AutoPackageRecipe):
    name = 'testpaket'
    version = '0.0.1'
    buildRequires = []
    def unpack(r):
        r.macros.upstreamVersion = r.macros.version.replace('_','-')
        r.addArchive('http://www.testpaket.de/%(name)s-%(upstreamVersion)s.tgz')

Um das neue Rezept auszuprobieren, begeben Sie sich mit cvc cook testpaket.recipe in die Küche. Conary versucht nun, anhand der gegebenen Informationen aus der recipe-Datei und aus dem Tarball ein Paket zu bauen. Conary teilt Ihnen im Verlauf mit, welche Abhängigkeiten Sie in die Liste buildRequires einzutragen haben. Gegebenenfalls müssen Sie den Kochprozess mehrfach anzustoßen, um alle Abhängigkeiten zu erfüllen. Das Rezept-Howto [12] enthält weitere Informationen.

Paket einpflegen

Meldet Cvc keine Fehler mehr, haben Sie die Möglichkeit das Paket ins Repository zu übergeben. Die Befehle cvc add testpaket.recipe && cvc commit -m "Mein erstes Paket." erledigen diese Aufgabe. Damit alle Troves respektive Komponenten für andere Benutzer und Appliances verfügbar gemacht werden, kochen Sie das Paket im Anschluss im Repository des Servers mit cvc cook testpaket. Stellen Sie sicher, dass die letzte Meldung Changeset committed to the repository. lautet. Nach diesem Schritt können Sie das Paket mit einem Webbrowser unter der Adresse http://testprojekt.rpath.org/ ansehen. Klicken Sie im linken Teil der Seite auf Project Resources | Browse Repository und im Anschluss auf testpaket. Show Contents listet sogar die Inhalte aller Troves auf, die das Paket umfasst.

Fazit

Conary ist eine wirklich bemerkenswerte Paketverwaltung, die es erlaubt, Pakete mit vielen Abhängigkeiten schmerzfrei zu installieren. Probleme, die die Entwickler derzeit bei APT und RPM durch immer neuere Algorithmen zu lösen versuchen, entstehen bei Conary wegen der feinkörnigen Versionierung erst gar nicht. Selbst das Erstellen von eigenen Paketen und das Heraufladen auf einen Server ist in Conary fest verankert – andere Lösungen müssen dazu externe Programme bemühen. Das Unternehmen rPath dürfte zukünftig mit seinem Paketmanagement neue Impulse und Ideen für eine noch einfachere und bessere Linux-Paketverwaltung liefern.