Serie: Pakete im Eigenbau

RPM-Pakete im Eigenbau LU 07/2013, S. 88 http://www.linux-community.de/28508
Debian-Pakete im Eigenbau LU 08/2013, S. 88 http://www.linux-community.de/28514
Arch-Pakete im Eigenbau LU 09/2013, S. XX http://www.linux-community.de/28515

Das einfach zu bedienende System zum Bauen von Paketen (Abbildung 1) gehört zu den Stärken von Arch Linux, die viele Poweruser für die leichtgewichtige Distribution einnimmt: Pakete, die Sie über den Paketmanager Pacman administrieren, entstehen auf der Basis eines einzigen Bash-Skripts mit dem Namen PKGBUILD, dessen Aufbau sich Anwendern mit Shell-Grundwissen schnell erschließt. Arch Linux veröffentlicht diese Dateien für alle offiziellen Pakete über das Build-System: Das Kommandos abs spielt sie in der aktuellen Version nach /var/abs ein.

Abbildung 1: Arch Linux stellt den Großteil der Software als Binärpakete bereit, bringt aber trotzdem ein optimiertes Build System mit, das die offiziellen Pakete – und nicht nur diese – mühelos auf dem eigenen Rechner kompiliert.

Der Paketmanager von Arch Linux installiert ohne Umstände lokal vorliegende Pakete. Es fällt jedoch nicht schwer, ein eigenes Repository zu erzeugen. Bei Bedarf ließe sich dies über einen HTTP- oder FTP-Server im Netz verteilen, sodass mehrere Systeme es bei jedem Upgrade der Rolling-Release-Distribution mit einbeziehen. Zum Erzeugen des Repositories reicht der Aufruf repo-add Reponame.db.tar.gz Paketdatei im Verzeichnis, in dem die Paketdateien liegen (Abbildung 2).

Abbildung 2: Um den Paketmanager Pacman herum haben die Entwickler von Arch Linux ein Ökosystem an Tools gestrickt, mit dem Sie bei Bedarf offizielle Pakete abgewandelt kompilieren oder eigene Pakete und Repositories erzeugen.

Wie bei anderen Distributionen verhindert das Paketmanagementsystem, dass neue Pakete Dateien aus bereits installierten überschreiben und schützen damit das System vor Schaden. Auf das unkontrollierte und oft irreversible Einspielen über make install brauchen Sie sich nicht einzulassen; erzeugen Sie besser gleich ein Paket.

Bauplan

Um ein offizielles Paket aus den Arch-Repositorys selbst zu kompilieren, genügt es, den Ordner /var/abs/Repository/Paketname> zu kopieren und aus diesem Verzeichnis heraus das im Paket pacman enthaltene Tool makepkg aufzurufen. Die Option -s gestattet es makepkg, fehlende Abhängigkeiten nachzuziehen, mit -i installiert die Software das Paket bei Erfolg.

Das selbe Vorgehen kommt auch bei nicht offiziell unterstützen Paketen aus dem Arch User Repository (AUR) (Abbildung 3) zum Einsatz, bis auf den Unterschied, dass die zum Paketbau nötigen Dateien hier zunächst als Tar-Archiv vorliegen.

Abbildung 3: Dank des Community-basierten Arch User Repository (AUR) stehen für Arch Linux ähnlich viele Programme bereit wie unter Debian. Beim Übersetzen der Software hilft das Build-System um makepkg.

Außer dem zentralen Skript liegen im Verzeichnis unter /var/abs oder im AUR manchmal noch Patch-Dateien, Desktop-Dateien für Menüeinträge oder andere Kleinigkeiten, die im ursprünglichen Quellcode des Programms fehlen. Den umfangreichen Quellcode selbst lädt dagegen erst der Aufruf von makepkg herunter.

Die Grundstruktur der Datei PKGBUILD erschließt sich schnell: Bash-Variablen definieren den Namen des Pakets und dessen Version sowie Abhängigkeiten, die Upstream-URL der Quelldateien sowie einige weitere Daten. In den Funktionen build() und package() stehen die Befehle, die Sie auf der Konsole zum Kompilieren und Installieren eintippen würden. Die Befehle, die Root-Rechte brauchen, gehören nach package(), alle anderen nach build(), das vor package() läuft. Weitere Elemente erläutert Tabelle "PKGBUILD im Detail".

<C>PKGBUILD<C> im Detail

Variable Bedeutung
pkgname Paketname
pkgver Version der verpackten Software
pkgrel Signalisiert neue Version der Bauvorschrift bei gleicher Version der Software
pkgdesc Kurzbeschreibung für die verpackte Software
arch Rechnerarchitektur, Standard ('i686' 'x86_64'), eventuell nur eine der beiden
url Upstream-URL
license Lizenz
groups thematische Paketgruppe (PKGBUILD eines ähnlichen Programms konsultieren)
depends Abhängigkeiten, Beispiel: ('gtk3' 'dbus-glib' 'libguess'), Versionen: 'paketname>=2.5.1'
optdepends optionale Abhängigkeiten, Array mit Einträgen der Form cups: printing support
makedepends Array mit nur zum Kompilieren benötigten Abhängigkeiten
provides Abhängigkeiten, die das Paket bedient, Beispiel: ('qt4=4.8.4')
conflicts Pakete, die mit diesem Paket kollidieren
replaces Namen älterer Pakete, die dieses Paket ersetzt
options Einstellungen aus /etc/makepkg.conf für dieses Paket überschreiben
install Install-Skript (vergleiche Listing 2)
changelog ChangeLog-Datei (vergleiche /usr/share/pacman/ChangeLog.proto)
source URLs der zum Kompilieren benötigten Dateien, bekannte Archivtypen packt die Software automatisch aus, Versionrepositories (URL: git://Pfad oder git+http://Pfad, analog hg für Mercurial, bzr für Bazaar und svn für Subversion)
md5sums/sha1sums/sha256sums/sha384sums/sha512sums Checksummen für jeden Eintrag in source, lautet bei Sourcen aus Versionrepositories SKIP, generierbar mit makepkg -g
noextract Archive aus source, die Makepkg nicht auspacken soll
Funktionen
prepare() optional, ab Pacman 4.1, Quellcode vorbereiten, makepkg -e überspringt den Schritt
build() ./configure und make oder entsprechende Befehle
check() optional, zum Beispiel make tests, wenn für die Software definiert
package() make install oder Entsprechung, läuft unter Fakeroot (schreibt Dateien mit Eigentümer root, aber aus Sicherheitsgründen keine echten administrativen Schreibrechte)
version() optional, für Git-, SVN-Pakete, Rückgabewert überschreibt pkgver

Alles weitere, nämlich das Herunterladen und Entpacken des Quellcodes, das Prüfen der Abhängigkeiten sowie das Verpacken in ein Arch-Programmpaket übernimmt Makepkg, ein etwa 3000 Zeilen langes Shell-Skript. Sind die beiden Funktionen fehlerfrei durchgelaufen, landen alle Dateien, die make install nach ${pkgdir} geschaufelt hat, im Paket.

Listing 1

pkgname=audacious
pkgver=3.3.4
pkgrel=1
pkgdesc='Lightweight, advanced audio player focused on audio quality'
url='http://audacious-media-player.org/'
license=('custom:BSD')
arch=('i686' 'x86_64')
depends=('gtk3' 'dbus-glib' 'libguess' 'libsm' 'audacious-plugins'
         'hicolor-icon-theme' 'desktop-file-utils')
optdepends=('unzip: zipped skins support')
source=("http://distfiles.audacious-media-player.org/${pkgname}-${pkgver}.tar.bz2")
sha1sums=('d1050fb88a59b46c0c9bbb1af0e7efc2b02f2b4d')
provides=('audacious-player')
replaces=('audacious-player')
install=install
build() {
     cd "${srcdir}/${pkgname}-${pkgver}"
     ./configure --prefix=/usr --with-buildstamp='Arch Linux'
     make
}
package() {
     cd "${srcdir}/${pkgname}-${pkgver}"
     make DESTDIR="${pkgdir}" install
     install -Dm644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

Datenerhebung

Listing 1 zeigt die Datei PKGBUILD für das offizielle Paket des Audio-Players Audacious, das sich nach Installation von abs und dem Abgleich mit einem Aufruf von abs unter /var/abs/extra/audacious findet.

Die Zeilen 1 bis 16 enthalten die Definitionen für elementare Daten, die das spätere Softwarepaket enthält: pkgname, pkgver und pkgdesc nennen Paketnamen, Programmversion und eine Beschreibung, die in Bezug auf die Länge 80 Zeichen nicht überschreiten sollte.

Die Variablen license und url liefern für den Anwender wichtige Informationen, haben aber keine technische Bedeutung beim Paketbau. Das Hochzählen der pkgrel (Paket-Release-Version) dagegen erzeugt Pakete, die der Paketmanager als Updates erkennt, obwohl sich die enthaltene Programmversion nicht geändert hat.

Das Bash-Array depends listet die Abhängigkeiten des Pakets auf. Leerzeichen trennen die einzelnen Einträge, die in einfachen Anführungszeichen stehen. Sie dürfen Zeilenumbrüche und Tabs zwischen den Elementen zum Formatieren verwenden, das stört die Bash nicht. Bei Leerzeichen vor oder nach dem Gleichheitszeichen versteht sie allerdings keinen Spaß.

Das Array makedepends enthält die Abhängigkeiten, die nur zum Kompilieren erforderlich sind, nicht aber zur Laufzeit des Programms. Bei Audacious gibt es keine solchen speziellen Abhängigkeiten, da Arch Linux keine gesonderten Devel-Pakete kennt. Der Eintrag optdepends listet schließlich noch optionale Abhängigkeiten, die zusätzliche Funktionalität bereit stellen. Die Einträge folgen der Form Paketname: Funktionserweiterung.

Die Variable replaces teilt Pacman mit, dass das vorliegende Paket ein älteres mit anderem Namen ersetzt. Das Feld provides kommt dagegen zum Einsatz, wenn mehrere Pakete einen funktional äquivalenten Inhalt bereit stellen. Eine selbstkompilierte Version von Qt4 hieße eventuell qt4-with-xxx. Trotzdem zöge der Paketmanager es als erfüllte Abhängigkeit für Qt4 betracht, wenn PKGBUILD den Eintrag provides=('qt4') enthielte.

In die Kategorie "Paketabhängigkeiten" gehört noch das Array conflicts=('...' ['...']), das das gleichzeitige Installieren bestimmter Pakete verbietet. Im Audacious-Beispiel gibt es keine solchen Kandidaten.

Aus der Quelle

Von den Elementen der Datei PKGBUILD, die den Paketbau selbst steuern, ist eine der wichtigsten Variablen das Array source, das alle für das Kompilieren und den Bau erforderlichen Dateien enthält. Das umfasst auch Dateien, die Sie über HTTP oder FTP erreichen.

Für den oft mehrerer Megabytes großen eigentlichen Quellcode sind in den offiziellen Repository und im Arch User Repository (AUR) lokale Dateien sogar verboten, damit das Arch Build System (Abs) und das AUR performant bleiben. Nur wenige Kilobytes große Dateien wie Patches, Icons oder Desktop-Dateien für Einträge im Startmenü dürfen direkt im selben Verzeichnis wie PKGBUILD liegen. In source referenzieren Sie diese lokalen Dateien mit dem bloßen Dateinamen.

Das Build-System prüft bei allen Dateien in source, ob es sich um ein Archiv in einem bekannten Format handelt und packt es gegebenenfalls aus. Die Befehle dafür braucht PKGBUILD also nicht zu enthalten.

Jedem Eintrag in source entspricht eine Checksumme in den Arrays md5sums, sha1sums, sha256sums, sha384sums oder sha512sums, die verhindert, dass der Online-Quellcode sich unbemerkt ändert. Die Prüfsummen entstehen mit Hilfe des Kommandozeilen-Tools mit dem Namen der Hash-Variablen. Jedes PKGBUILD muss sich für eine der genannten Alternativen entscheiden und die Checksummen in der gleichen Reihenfolge wie die Quelldateien in source auflisten.

Bleibt noch die Variable install, die auf ein Shell-Skript mit dem Funktionen pre_install(), post_install(), pre_upgrade(), post_upgrade(), pre_remove() und post_remove() verweist. Ist ein solches Skript angegeben, ruft Pacman es beim Installieren oder Deinstallieren auf.

Im Audacious-Beispiel (Listing 1) nimmt das Skript install nach dem Installieren, Upgrade oder Entfernen des Pakets ein Update der systemweiten Mimetype-Datenbank sowie des Gtk-Icon-Caches vor. Dabei braucht das Skript nur die tatsächlich benötigten Hooks zu enthalten. Er muss im selben Verzeichnis liegen wie PKGBUILD.

Arbeitstiere

Die Funktionen build() und package() leisten die eigentliche Arbeit beim Bauen des Pakets. In ihnen stehen die Befehle, die die Software kompilieren und in ein Unterverzeichnis relativ zum Home des Benutzers ("fake root") installieren. Diese Befehle fallen in der Regel für jede Software anders aus, obwohl oft der Dreischritt ./configure; make; make install zum Einsatz kommt.

Das bedeutet, dass Sie die Funktionen für jede Build-Datei neu schreiben müssen. Allerdings finden Sie unter /usr/share/pacman Templates, die nach Ausfüllen der Variablen für unkomplizierte Software direkt funktionieren.

Die Entwickler haben das Bauen und Kompilieren nicht ohne Grund in zwei Funktionen aufgeteilt: package() läuft in einer so genannten Fakeroot-Umgebung, in der die Funktion Dateien erstellen darf, die Root gehören. Das trifft aus Sicherheitsgründen auf fast alle Dateien in Programmpaketen zu. Verzeichnisse, für die nur Root Schreibrechte besitzt, bleiben ihr aber trotzdem verschlossen.

Das ist wichtig, falls ein aus dem Ruder laufender Prozess versucht, Dateien direkt im echten Root des Dateisystems zu installieren und dabei das System zu beschädigen. Insbesondere die Tests von configure schlagen allerdings in der solchen Umgebung zum Teil fehl. Deshalb gehören nur die Befehle, die die simulierten Root-Rechte wirklich brauchen, in die Funktion package().

Bauen und Packen

Im Beispiel für Audacious-Beispiel steht am Anfang jeweils ein Wechsel ins Verzeichnis ${srcdir}/${pkgname}-${pkgver} an. Diese Kombination aus Variablen expandiert zum Verzeichnis, in das der Aufruf makepkg die Quellen entpackt hat. Es handelt sich dabei im Beispiel um src/audacious-3.3.4 unterhalb des Arbeitsverzeichnisses oder an der in /etc/makepkg.con für SRCDEST festgelegten Stelle. Das braucht Sie innerhalb von PKGBUILD aber nicht weiter zu kümmern.

In build() folgt auf den Wechsel ins Verzeichnis der Aufruf von Configure. Wichtig ist dabei die Option --prefix=/usr: Meistens landen die Programmdateien ohne diesen Parameter in /usr/local, um nicht mit den über das Paketsystem installierten Programm zu kollidieren. Darum findet sich die Prefix-Angabe /usr in allen offiziellen Arch-Paketen. Der Parameter --with-buildstamp ist Audacious-spezifisch und hängt nicht direkt mit dem Bau des Pakets unter Arch Linux zusammen.

In package() steht direkt nach den Wechsel ins Quellcode-Verzeichnis der Aufruf von make install. Dem Parameter DESTDIR="${pkgdir}" kommt dabei eine besondere Bedeutung zu: Er sorgt dafür, dass der Aufruf make install die Dateien in eine Verzeichnishierarchie relativ zu ${pkgdir}, dem "fake root", und nicht im echten Root des Dateisystems installiert.

Es hängt vom Makefile des Programms ab, ob der Trick mit DESTDIR funktioniert. Wenn nicht, fällt es in der Regel schwer, ein Paket zu bauen [1]. Egal, ob unter Arch Linux, Debian/Ubuntu oder OpenSuse: Ein make install scheitert, weil es versucht, ohne Root-Rechte nach /usr oder in andere nur root zugängliche Verzeichnisse zu schreiben. Die meisten Entwickler berücksichtigen DESTDIR in den Makefiles, da sie wissen, dass die Paketsysteme der Distributionen darauf setzen.

In der letzten Zeile von package() folgt noch ein Aufruf von GNU Install. Er kopiert lediglich die Datei COPYING in das unter Arch Linux dafür übliche Verzeichnis. Der Parameter -DM644 erstellt dieses Verzeichnis, wenn es noch nicht existiert, und sorgt für angemessene Dateirechte. Abbildung 4 zeigt den gesamten Ablauf bei einem Aufruf von makepkg.

Abbildung 4: Ein makepkg führt bis zu vier in PKGBUILD definierte Funktionen aus. Die gestrichelt Dargestellten dürfen wegfallen. Parameter beschränken den Ablauf auf bestimmte Phasen (rechts im Bild).

Vorwissen

Mit diesem Wissen gelingt es bereits, Pakete für viele Programme zu erzeugen, die Sie erfolgreich kompiliert haben. Schon das Übersetzen aus den Quellen ist jedoch oft ein mühsames Unterfangen.

Das Experimentieren mit dem Compiler bleibt Ihnen häufig erspart, wenn Sie ein bestehendes Paket aus dem Arch-Build-System oder dem Arch User Repository auf eine neue Programmversion updaten. Wie Sie im PKGBUILD für das Beispiel Audacious sehen, bezieht die URL des Quellcodes in source die Variable pkgver ein.

Die Templates für PKGBUILD geben diesen Einsatz der Variablen für Versionsnummern vor und die offiziellen Arch-Pakete halten sich an diese Konvention – schon weil das Aktualisieren der ganzen Distribution anders kaum zu stemmen wäre.

Mit etwas Glück brauchen Sie daher nur pkgver anzupassen, sobald Version 3.3.5 von Audacious erscheint. Das Tool updpkgsums aktualisiert daraufhin die Prüfsummen. Wenn sich in der Quellcode-URL tatsächlich nur die Versionsnummer verändert hat, und das Programm wie bei der Vorgängerversion kompiliert, erzeugt makepkg ein aktuelles Audacious-Paket.

Natürlich ist es keineswegs sicher, dass ein ansonsten unverändertes PKGBUILD nach dem Erhöhen der Versionsnummer noch funktioniert: Es könnten neue Optionen beim Configure hinzugekommen sein oder die installierten Bibliotheken passen in Bezug auf die Version nicht zu denen, auf die das Programm aufsetzt.

Bei Sprüngen der Minor-Version, also der Zahl hinter dem ersten Punkt, kommt es jedoch erfahrungsgemäß eher selten zu Problemen. Rührt sich der Maintainer also trotz Out-of-Date-Flag (Abbildung 5) nicht, holen Sie sich mit abs die passende Datei PKGBUILD, passen pkgver an und probieren ihr Glück. Das gilt natürlich selbst dann, wenn Sie eine Beta-Version ausprobieren möchten oder in die offiziellen Version ein Feature einkompilieren möchten.

Abbildung 5: Ein Klick auf Flag Package Out-of-Date in der Arch-Linux-Paketdatenbank benachrichtigt den Maintainer. Statt auf seine Reaktion zu warten, gelingt es oft, mit wenig Aufwand selbst ein aktualisiertes Paket zu bauen.

Tagesaktuell

Es gibt Gründe, Pakete aus den offiziellen Repositories leicht abgewandelt auf dem eigenen Rechner neu zu übersetzen. So richtig stellt das Arch Build System seine Leistungsfähigkeit bei Paketen unter Beweis, deren Quellcode aus einem Versionsmanagementsystem stammt. Hier lohnt es sich, den Compiler öfters, vielleicht sogar täglich anzuwerfen. Solche Pakete finden sich naturgemäß nicht in den stabilen Repositorys, aber im AUR stehen viele bereit.

Pacman 4.1 ersetzt dabei das frühere, etwas undurchsichtige Verfahren, bei dem makepkg bei allen Paketen, deren Name auf -git, -svn, -hg, -darcs oder -bzr endete, das aktuelle Datum als Versionsnummer verwendet hat.

Bei diesem neuen Verfahren ist es nicht einmal mehr nötig, die Befehle für den Checkout oder Update des Quellcodes in das Build-Skript zu schreiben. Vielmehr akzeptiert makepkg nun direkt im Array source URLs, die auf ein Repository deuten und automatisiert den Checkout ähnlich dem Auspacken von Archiven mit Quellcode.

Listing 2

pkgname=audacious-git
pkgver=0
pkgrel=1
pkgdesc='Lightweight, advanced audio player focused on audio quality'
url='http://audacious-media-player.org/'
license=('custom:BSD')
arch=('i686' 'x86_64')
depends=('gtk3' 'dbus-glib' 'libguess' 'libsm' 'hicolor-icon-theme' 'desktop-file-utils')
makedepends=('git')
optdepends=('unzip: zipped skins support')
provides=('audacious')
conflicts=('audacious' 'audacious-player-hg')
source=('git://github.com/audacious-media-player/audacious.git')
install=$pkgname.install
sha256sums=('SKIP')
pkgver() {
  cd "$srcdir/audacious"
  git describe --always | sed 's|-|.|g'
}
build() {
    cd "$srcdir/audacious"
    autoreconf
    ./configure --prefix=/usr --with-buildstamp="$(date +%x)"
    make
}
package() {
    cd "$srcdir/audacious"
    make DESTDIR="${pkgdir}" install
    install -Dm644 COPYING "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
}

Version für Version

Listing 2 zeigt als Beispiel das PKGBUILD für eine Git-Version von Audacious. Die offensichtlichste Änderung im Vergleich zur auf einem statischen Tar-Archiv basierenden Fassung (Listing 1) besteht in der Git-URL in source (Zeile 14). Anhand des Protokolls erkennt makepkg das Versionskontrollsystem und sorgt dafür, dass der Quellcode vor dem Aufruf von build() in der neuesten Version vorliegt.

Nach wie vor darf source mehrere Quellen bündeln und dabei statische und versionierte Elemente mischen. Da Checksummen bei letzteren keine Sinn ergeben, lautet der zugehörige Eintrag sha256sums schlicht SKIP. Falls Sie statt des Git-eigenen Protokolls lieber Git über HTTP verwenden möchten, beginnt die URL mit git+http.

Hinzugekommen ist außerdem die Funktion pkgver() (Zeile 18). Sie gibt im vorliegenden Fall den Hash des aktuellen Checkins zurück [2]. makepkg verwendet den Rückgabewert als Paketversion. Das erlaubt es, jedes neu übersetzte Paket einzuordnen. Aus diesem Grund darf die Variable pkgver mit einem beliebigen Wert starten.

Über makepkg --holdver stoßen Sie ein Neukompilieren ohne Update des Quellcodes an. Dies ist aber nur beim Testen während des Schreiben von PKGBUILD-Dateien erforderlich, da ein Neubau des Pakets andere, bereits erzeugte Versionen nicht überschreibt. Solange Sie diese nicht löschen, bleibt daher immer die Option auf ein Downgrade zu einer Versionen aus einem früheren Aufruf.

Eine kleine Änderung ergibt sich beim Wechsel in das Quellcode-Verzeichnis am Anfang der drei Funktionen: Während makepkg den Ordner explizit nach dem Paketnamen und der Versionsnummer benennt, wenn es ein Tar auspackt, ergibt sich der Verzeichnisnahme hier beim Checkout, den Namen audacious gibt das Versionsrepository vor.

Vor dem Aufruf von Configure in build() muss autoreconf das Skript erst noch erzeugen, da es nicht üblich ist, es ins Rrepository einzuchecken. Darüber hinaus passen Sie das Array conflicts an, das die Deinstallation des offiziellen Audacious-Pakets erzwingt. Es enthält in Konflikt stehende Dateien.

Leichtbauweise

Arch Linux strebt beim Thema Paketbau nach Einfachheit, dem erklärten Kernziel seiner Entwickler: Das Build System setzt auf die altbewährte Bash, und erschwert den Einstieg nicht durch unnötige Komplexität. Weitere Details zum Paketbauprozesses liefert umfassend und aktuell das Arch-Wiki [3] oder die Manpages zu makepkg und PKGBUILD.

Allerdings hält das Paketmanagement von Arch Linux beim Verwalten von Abhängigkeiten nicht mit seinen Geschwistern aus der Debian- und RPM-Welt mit: Beide Systeme klopfen beim Bau alle Binärdateien auf verlinkte Libraries ab, der Entwickler braucht nur in Ausnahmefällen Abhängigkeiten per Hand einzutragen. Arch-Pakete prüfen dagegen immer nur in PKGBUILD eingetragenen Abhängigkeiten, die Sie aber leicht mit Hilfe von Namcap [4] ermitteln.

Wer selbst übersetzte Pakete aus dem AUR auf seinem System installiert hat, ist mitunter auf das Problem gestoßen, dass ein solches Programm mit Meldungen wie libxxx.so.y.z: Kann die Shared-Object-Datei nicht öffnen abstürzt. Um solche unliebsamen Überraschungen zu vermeiden, die keineswegs immer gleich beim Start zu Tage treten, enthalten RPM- und Debian-Pakete Informationen zum so genannten Soname [5] der verlinkten Bibliotheken, die sich aus der an die Dateiendung .so angehängten Versionsnummer der Bibliotheksdatei ableitet.

Mit einer Veränderung des Sonames signalisieren die Entwickler der Bibliothek einen Bruch der Binärkompatibiltät, die ein Neukompilieren aller verlinkten Programmdateien erforderlich macht. Er steht in keinem direkten Zusammenhang zu den Releases einer Bibliothek. Darum hilft das Management der Abhängigkeiten in Pacman, das nur Paketversionen erfasst, hier nicht weiter.

In der Praxis sind Pakete unter Arch Linux daher meist überhaupt nicht an eine bestimmte Library-Version gebunden, denn ein Bruch der Binärkompatiblität bei neuen Versionen einer Bibliothek gehört eher zu den Ausnahmen als der Regel. Bei den offiziellen Repositories schützt ein gleichzeitiges Update aller Pakete aus dem immer im Zusammenhang getesteten Pool von Paketen vor dem beschriebenem Problem. Das gilt jedoch nicht bei selbst gebauten Paketen.

Fazit

Arch Linux gehört zu den wenigen Distributionen, die das Bauen von Paketen n nicht primär an den Anforderungen professioneller Maintainer ausrichten. Darum genügen für Archive der Marke Eigenbau ein Template und ein Editor, mit dem Sie Daten wie Paketname oder Version zu ergänzen. 

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 7 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

LinuxCommunity kaufen

Einzelne Ausgabe
 
Abonnements
 

Ähnliche Artikel

Kommentare