Als Rolling-Release-Distribution steht Arch Linux vor der Herausforderung, täglich neue Anwendungen und Updates verwalten zu müssen. Der Arch-Paketmanager Pacman stemmt die Arbeit ohne Murren und Knurren. Den offiziellen Paketquellen steht das Arch User Repository zur Seite.

“Never change a running system”, lautet eine altbekannte Devise. Wer erst einmal sein System perfekt eingerichtet hat, der sollte in Zukunft besser nicht zu viel ändern. Im Endeffekt halten sich die meisten Distributionen an diese Regel: Nach der Veröffentlichung spielen die Entwickler nur noch Sicherheitsupdates und essentielle Fehlerbereinigungen in die Paketverwaltung ein, neue Programmversionen gibt es nur fein dosiert.

Die Paketverwaltung der Rolling-Release-Distribution Arch Linux [1] muss deutlich mehr bewerkstelligen: Tagtäglich laufen neue Programme und Programmversionen auf, die in die Paketquellen einpflegt werden möchten. Diese Arbeit übernehmen auch bei Arch Paketbetreuer, in der Regel unentgeltlich als freiwillige Helfer. Als Anwender kommen Sie bereits bei der Installation des Systems mit der Arch-Paketverwaltung in Berührung [2], da die Distribution keinen Installer bietet und Sie Ihr persönliches Arch-System von Hand zusammenbauen müssen – oder besser dürfen.

Kein Spiel: Pacman für Arch

Der zentrale Paketmanager bei Arch Linux nennt sich Pacman. Das Programm verwaltet einfache Binärpakete im Format .pkg.tar.xz (früher einmal .pkg.tar.gz), die das Programm in der Regel aus den offiziellen Paketquellen bezieht. Es lassen sich allerdings auch inoffizielle Paketquellen einbinden und so nicht direkt unterstützte Programme über die Paketverwaltung installieren. Alternativ bauen Sie über das Arch Build System (ABS) in eigener Regie Programme und spielen diese dann per Pacman ein. So landen diese wie die aus den Paketquellen installierten Pakete in der zentralen Datenbank, was Dateikonflikte vermeidet.

Im Gegensatz zum dynamischen Debian-Duo dpkg und apt-get übernimmt Pacman sämtliche Aufgaben allein: Es sucht in der Datenbank (Listing 1), lädt Pakete herunter, installiert (Listing 2) und aktualisiert diese. Das Tool überprüft die Installation oder löscht nicht mehr gewünschte Programme von der Festplatte. Dabei müssen Sie mit kryptischen Optionen wie -Ss, -Syu oder -Runs Vorlieb nehmen (siehe Tabelle “Pacman-Befehle”). Dies erschwert den Einstieg ein wenig, da sich solche Kommandos nur schwer einprägen lassen. Eine grafische Oberfläche wie Synaptic oder das Ubuntu Software Center gibt es für Pacman nicht – zumindest nicht offiziell.

$ pacman -Ss chromium
extra/chromium 43.0.2357.134-1
    The open-source project behind Google Chrome, an attempt at creating a
    safer, faster, and more stable browser
extra/qt5-webengine 5.5.0-1 (qt qt5)
    Provides support for web applications using the Chromium browser project
community/chromium-bsu 0.9.15.1-1 [Installiert]
    A fast paced top scrolling shooter
[...]

# pacman -S chromium
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...
Paket (1)       Neue Version     Netto-Veränderung
extra/chromium  43.0.2357.134-1         166,80 MiB
Gesamtgröße der zu installierenden Pakete:  166,80 MiB
:: Installation fortsetzen? [J/n] j
(1/1) Prüfe Schlüssel im Schlüsselring             [----------------------] 100%
[...]
(1/1) Installiere chromium                         [----------------------] 100%
Optionale Abhängigkeiten für chromium
    kdebase-kdialog: needed for file dialogs in KDE
    gnome-keyring: for storing passwords in GNOME keyring [Installiert]
    kdeutils-kwalletmanager: for storing passwords in KWallet

Arch teilt seine Paketquellen in sechs unterschiedliche Zweige auf (Tabelle “Arch-Repositories”). Die wichtigsten Pakete, wie der Kernel, GCC oder zentrale Tools zum Bauen von Programmen stammen aus Core. An diesen Paketen dürfen nur die Stammentwickler Hand anlegen, genauso wie an den Paketen aus Extra. Zu Letzteren zählen zentrale Linux-Komponenten wie X-Server oder Desktop-Umgebungen sowie wichtige Programme wie Firefox, LibreOffice oder Vim. Die Community-Repositories entsprechen im Prinzip den Universe-Quellen Ubuntus. Etwa 40 erfahrene und vertrauenswürdige “Trusted User” [3] kümmern sich um zahlreiche Programme, die es bisher noch nicht in die Kerndistribution geschafft haben.

Pacman-Konfiguration

Die Konfiguration von Pacman geschieht über die Datei /etc/pacman.conf. Sie beinhaltet nicht nur Informationen, welche Paketquellen wo zu benutzen sind (oft über Mirror-Listen eingebunden), sondern bestimmt auch das Verhalten des Paketmanagers. So lassen sich hier zum Beispiel über die Optionen IgnorePkg und IgnoreGroup gezielt Pakete oder gleich ganze Gruppen vom Update-Prozessen ausklammern (Listing 3). Beachten Sie jedoch, dass Arch Linux als Rolling-Release-Distribution konzipiert ist und Sie durch die Blockade eines Pakets auch die Aktualisierung seiner Abhängigkeiten unterbinden (Listing 4). Nach längerer Zeit zieht sich ein Rattenschwanz an blockierten Paketen durch das System.

[...]
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup
IgnorePkg   = gimp darktable
IgnoreGroup = kde kdebase kdeutils libreoffice qt kdeplasma
[...]

# pacman -Syu
:: Synchronisiere Paketdatenbanken...
 core ist aktuell
[...]
:: Starte vollständige Systemaktualisierung...
Warnung: linux: Ignoriere Paket-Aktualisierung (4.0.7-2 => 4.1.2-2)
Warnung: linux-headers: Ignoriere Paket-Aktualisierung (4.0.7-2 => 4.1.2-2)
Löse Abhängigkeiten auf...
Warnung: Ignoriere Paket linux-4.1.2-2
Warnung: Kann "linux>=4.1" nicht auflösen (eine Abhängigkeit von "virtualbox-host-modules")
:: Das folgende Paket kann aufgrund nicht auflösbarer Abhängigkeiten nicht aktualisiert werden:
      virtualbox-host-modules

Pacman optisch ein wenig aufzubohren, birgt hingegen keine Gefahren (Listing 5). Unter den Misc options schalten Sie ein wenig Farbe hinzu (Color), erweitern die Ausgabe der Paketänderungen von Pacman um eine Gegenüberstellung der Versionsnummern und Paketgrößen (VerbosePkgLists (für die Darstellung müssen Sie das Terminal etwas größer als die üblichen 80 Zeichen ziehen) oder verwandeln den Fortschrittsbalken mit einem zusätzlich eingefügten ILoveCandy in einen wahrhaftigen Pac-Man (Abbildung 1).

[...]
# Misc options
#UseSyslog
Color
#TotalDownload
CheckSpace
VerbosePkgLists
ILoveCandy
[...]

Abbildung 1: Mit den richtigen Einstellungen gibt Pacman deutlich mehr Informationen zu den anstehenden Aktualisierungen aus.

Am Ende der /etc/pacman.conf liest Pacman die aufzusuchenden Paketquellen aus. Core, Extra und Community aktivieren die meisten User; Multilib dient dazu, 32-Bit-Software auf einem 64-Bit-System auszuführen. Auch diese Quelle gehört daher bei vielen Arch-Nutzern zum Standardrepertoire. Von Testing und Multilib-Testing sollten Sie eher Abstand nehmen: Diese Quellen dienen wie eingangs beschrieben zum Testen neuer Pakete, die erst nach erfolgreich bestandener Prüfung in die herkömmlichen Paketquellen wandern. Die Standardquellen bezieht Pacman aus der Datei /etc/pacman.d/mirrorlist. Sie enthält eine Liste sämtlicher Arch-Mirrors [4], von denen allerdings die meisten auskommentiert sind.

Bei Bedarf aktivieren Sie sämtliche Mirrors aus Ihrer Region – beispielsweise Deutschland – und prüfen dann mit rankmirrors, welcher davon am schnellsten arbeitet (Listing 6). Die schnellsten Mirror-Server kopieren Sie dann aus der pacman.conf in die neu zu erstellende Datei /etc/pacman.d/mymirrors (Listing 7) und referenzieren diese zusätzlich in allen Sektionen der pacman.conf vor der Original-Mirrorlist (Listing 8). So nutzt Pacman immer die lokal schnellsten Mirror-Server, auch wenn es zu Änderungen an der über das Paket pacman-mirrorlist verwalteten Mirrorlist kommt.

$ rankmirrors -n 0 -t -v /etc/pacman.d/mirrorlist
Querying servers. This may take some time...
http://ftp.hawo.stw.uni-erlangen.de/archlinux/$repo/os/$arch ... 0,093
http://mirror.netcologne.de/archlinux/$repo/os/$arch ... 0,090
http://ftp.tu-chemnitz.de/pub/linux/archlinux/$repo/os/$arch ... 0,159
http://ord.mirror.rackspace.com/archlinux/$repo/os/$arch ... 0,945
Servers sorted by time (seconds):
http://mirror.netcologne.de/archlinux/$repo/os/$arch : 0,090
http://ftp.hawo.stw.uni-erlangen.de/archlinux/$repo/os/$arch : 0,093
http://ftp.tu-chemnitz.de/pub/linux/archlinux/$repo/os/$arch : 0,159
http://ord.mirror.rackspace.com/archlinux/$repo/os/$arch : 0,945

Server = http://mirror.netcologne.de/archlinux/$repo/os/$arch
Server = http://ftp.hawo.stw.uni-erlangen.de/archlinux/$repo/os/$arch
Server = http://ftp.tu-chemnitz.de/pub/linux/archlinux/$repo/os/$arch

[...]
[core]
Include = /etc/pacman.d/mymirrors
Include = /etc/pacman.d/mirrorlist
[...]

Zusätzliche Paketquellen

Manche unabhängigen Arch-Entwickler und Communities betreiben eigene, nicht offiziell abgesegnete Paketquellen, die sich relativ einfach zum System hinzufügen lassen. Diese Repos enthalten in der Regel Binärpakete, sodass ein langwieriges Kompilieren der Anwendungen entfällt. Die Installation eines alternativen Kernels oder gar einer kompletten Desktop-Umgebung beschleunigt sich auf diese Weise ganz wesentlich.

Das Arch-Linux-Wiki führt eine ganze Reihe solcher inoffizieller Paketquellen auf [5]. Zudem erleichtern Paketbetreuer wie etwa die Mitglieder des Gnome-Teams die Installation von Testversionen über die Paketverwaltung mit einem eigenen Repository. Solche Informationen verbergen sich jedoch oft tief in den Arch-Foren [6] – schließlich sollen nur interessierte Tester diese Paketquellen nutzen, nicht aber Anwender, die so ein paar Tage früher an die neuste Gnome-Version kommen möchten.

Zum Einfügen einer neuen Paketquelle öffnen Sie die Pacman-Konfigurationsdatei /etc/pacman.conf in einem Editor und übernehmen den jeweiligen Eintrag, bestehend aus einer [Definition] in eckigen Klammern und der Server-Zeile mitsamt einer URL, unter der die Quelle zu erreichen ist. Listing 9 zeigt als Beispiel die Paketquelle für das Infinality-Bundle [7], das durch Einbringen mehrerer Änderungen an den Freetype2-Bibliotheken [8] die Darstellung von Schriften erheblich verbessert [9]. Teile dieser Änderungen kollidieren allerdings mit einer Reihe von Softwarepatenten, daher lassen sich diese Verbesserungen nicht in die Originalbibliotheken von Haus aus implementieren.

[infinality-bundle]
Server = http://bohoomil.com/repo/$arch

Nach dem Sichern der Änderungen an der pacman.conf müssen Sie bei signierten Paketquellen (im englischen “signed”) der Schlüsseldatenbank von Pacman den öffentlichen Schlüssel des Entwicklers hinzufügen. Dies gelingt mittels des Befehls pacman-key -r Key-ID, bei dem Sie die Key-ID entsprechend anpassen – die Liste mit den inoffiziellen Arch-Repos im Wiki listet die IDs immer mit auf. Anschließend quittieren Sie den Schlüssel mit der Option --lsign-key, lesen die Paketquellen mit Pacman neu ein und installieren dann das Bundle – oder bei einer anderen Paketquelle eben das gewünschte Paket (Listing 10).

# pacman-key -r 962DDE58
# pacman-key --lsign-key 962DDE58
# pacman -Syu
# pacman -S infinality-bundle

Eine Übersicht über alle Pakete eines Repositories erhalten Sie bei Bedarf mittels pacman -Sl Quelle. Der Befehl listet alle in der angeführten Quelle verfügbaren Pakete auf und markiert die bereits installierten (Listing 11), sodass sich diese dann gezielt löschen lassen. Um das Repository dann endgültig zu löschen, entfernen Sie den entsprechenden Eintrag in der pacman.conf. Im Fall des Infinality-Bundles sollten Sie jedoch besser mit pacman -S freetype2 fontconfig cairo die ungepatchten Bibliotheken installieren und die dann im Konflikt stehenden Infinality-Pakete entfernen lassen, sodass es nicht zu unzähligen fehlenden Abhängigkeiten kommt.

$ pacman -Sl infinality-bundle
infinality-bundle cairo-infinality-ultimate 1.14.2-1 [Installiert]
infinality-bundle fontconfig-infinality-ultimate 2.11.1-28 [Installiert]
infinality-bundle fontconfig-iu-comp 2.11.1-4
infinality-bundle jdk8-openjdk-infinality 8.u45-2
[...]

Arch User Repository

Nun erstreckt sich das Open-Source- und Linux-Universum über weitaus größere Dimensionen, als die Stammentwickler und Trusted User von Arch Linux abdecken können. Zahlreiche interessante aktuelle Programme und Entwicklungen müssen sich erst bewähren, bevor sie den Weg in die Community-Repos und später vielleicht einmal nach Extra finden. In diese Kategorie fallen beispielsweise brandneue Programme direkt vom Entwickler, experimentelle Patches oder kommerzielle Anwendungen, die gar nicht frei verteilt werden dürfen.

Arch begegnet diesem Problem mit dem Arch User Repository [10] oder kurz AUR. Das AUR agiert nicht als weitere Paketquelle, sondern stellt eine Sammlung aus “Kochrezepten” dar, die beschreiben, wie das System eine Anwendung installieren soll. Dabei spielt es keine Rolle, wie das Programm vorliegt: ob als Tarball, als Quellcode bei Github, als DEB- oder RPM-Paket oder in Form eines Archivs, das ein statisch kompiliertes Binary eines proprietären Programms enthält.

Eine Reihe [11] verschiedener AUR-Helper unterstützen Sie dabei, solche Anwendungen möglichst ohne Aufwand zu installieren. Sie übernehmen die Arbeit, die PKGBUILD-Datei zu interpretieren, die jedes AUR-Paket definiert. Dabei arbeitet der Helper das Kochrezept Schritt für Schritt ab und installiert am Ende das fertige Programm im System. Viele AUR-Helper arbeiten mit einer weitgehend zu Pacman identischen Syntax und leiten den Aufruf bei der Installation von Programmen aus den regulären Quellen zu Pacman durch. Für alltägliche Aufgaben, wie die Installation eines neuen Pakets oder dem Update des Systems, müssen Sie daher nicht extra Pacman starten.

Die Mutter aller AUR-Helper nennt sich Yaourt [12]. Der Name steht als Akronym für “Yet AnOther User Repository Tool”. Das Programm findet sich nicht in den Arch-Paketquellen, Sie müssen es aus dem AUR installieren. Hier beißt sich die Schlange quasi in den Schwanz: Schließlich wollen Sie gerade den ersten AUR-Helper installieren. Die Lösung findet sich in der manuellen Installation des Programms mitsamt seiner Abhängigkeiten. Detaillierte Hinweise dazu finden Sie im Arch-Wiki [13]. Noch simpler klappt es, wenn Sie Paketquellen der französischen Arch-Community einbinden und Yaourt so direkt als Binary installieren.

Öffnen Sie dazu, wie schon zuvor beschrieben, die /etc/pacman.conf mit Root-Rechten in einem Editor und fügen am Ende den Inhalt aus Listing 12 ein. Anschließend lesen Sie mit pacman -Syu yaourt die Paketquellen neu ein und spielen im selben Zug Yaourt auf das System. Falls Sie sudo zum Erlangen von Root-Rechten aus dem aktuellen Benutzerkontext noch nicht installiert haben sollten, holen Sie dies für den bequemen Gebrauch der meisten AUR-Helper noch nach [14]. Der Hintergrund liegt darin, dass Sie Yaourt und Co. immer nur mit Benutzerrechten aufrufen, sodass das Laden und Bauen der Anwendung im Userspace geschieht. Erst bei der Installation des Pakets fordert Yaourt administrative Rechte an.

[archlinuxfr]
SigLevel = Optional TrustAll
Server = http://repo.archlinux.fr/$arch

Zur Installation eines Programms orientieren Sie sich an der Syntax von Pacman und tauschen einfach nur den Programmnamen aus. Mit yaourt -Ss Suchbegriff starten Sie zum Beispiel die Suche und spielen einen der Treffer mit yaourt -S Paket ein (Listing 13). Dabei durchsucht Yaourt nicht nur das AUR, sondern führt an erster Stelle immer Treffer aus den herkömmlichen Paketquellen auf. Daher können Sie auch diese Pakete dann mit Yaourt installieren beziehungsweise mit yaourt -Syu gleich das gesamte System auf einen aktuellen Stand bringen. Achten Sie bei den AUR-Treffern auf die Zahl hinter dem Eintrag (im Beispiel die 1046), auf Zusätze wie Out of Date sowie auch die Farbkennzeichnung der Versionsnummer.

$ yaourt -Ss chrome
extra/chromium 43.0.2357.134-1 [installed]
    The open-source project behind Google Chrome, an attempt at creating a
    safer, faster, and more stable browser
infinality-bundle-fonts/ttf-croscore-fonts-ibx 1.23-9 (infinality-bundle-fonts-extra)
    Google Chrome OS core fonts.
[...]
aur/google-chrome 43.0.2357.134-1 [installed] (1046)
    An attempt at creating a safer, faster, and more stable browser (Stable
    Channel)
[...]
aur/chromeos-devkeys R30.4537-1 (Out of Date) (0)
    Chrome OS vboot keys
[...]
$ yaourt -S google-chrome

Die Zahl beziffert die Anzahl an Stimmen, die Arch-Nutzer dem AUR-Eintrag gegeben haben. Je mehr Stimmen, desto höher die Wahrscheinlichkeit, dass Sie dieses Programm ohne Komplikationen installieren können. Out of Date markiert Anwendungen, zu denen es eine neue Version gibt, sodass die PKGBUILD-Datei vom Betreuer des Pakets angepasst werden müsste (Abbildung 2). Eine rote Versionsnummer signalisiert, dass das Paket keinen Betreuer mehr hat – erwarten Sie hier also nicht zu viel. Bei einer grünen Versionsnummer kümmert sich hingegen nach wie vor jemand um das Paket.

Abbildung 2: Achten Sie bei der Installation von Paketen aus dem AUR immer auf die Anzahl der Votes. Rot hinterlegte Versionsnummern markieren veraltete Versionen.

Bei der Installation eines AUR-Pakets mit Yaourt flutet Sie das System nun mit Nachfragen und Warnungen wie Nicht unterstütztes Paket: Potenziell gefährlich!, PKGBUILD bearbeiten?, Mit dem Erstellen von google-chrome fortfahren?. Zudem müssen Sie oft noch Abhängigkeiten aus den normalen Paketquellen oder aus dem AUR nachziehen. Bei einem Programm mit vielen Anwendungen erfordert Yaourt immer wieder manuelle Eingriffe (siehe Kasten “Sicherheit”). Kontrollieren Sie daher stets die PKGBUILD-Datei dahingehend, ob zumindest die Quelle oder die URL stimmt, von der sich Yaourt die Software holen soll. Listing 14 zeigt den entsprechenden Ausschnitt für das Google-Chrome-Paket.

[...]
source_i686=("google-chrome-${_channel}_${pkgver}_i386.deb::https://dl.google.com/linux/direct/google-chrome-${_channel}_current_i386.deb")
source_x86_64=("google-chrome-${_channel}_${pkgver}_amd64.deb::https://dl.google.com/linux/direct/google-chrome-${_channel}_current_amd64.deb")
[...]

Schnelles Pacaur

Installieren Sie ein Programm mit zahlreichen nur im AUR verfügbaren Abhängigkeiten, müssen Sie Yaourt unentwegt unter die Arme greifen. Viele Nutzer stellen Yaourt deswegen so ein, dass es seine Arbeit stumm erledigt und zu allem Ja und Amen sagt. Das gedankenlose Abnicken jeder PKGBUILD, ohne auch nur die Quellen zu prüfen, birgt die Gefahr, eines Tages mit einem kompromittierten System dazustehen. Unser Tipp: Wechseln Sie besser auf einen etwas komfortableren AUR-Helper.

Ein entsprechender Kandidaten wäre zum Beispiel Pacaur [15]. Es arbeitet die PKGBUILD-Files nicht nach und nach ab und muss daher auch nicht immer wieder auf Ihre Antworten warten. Stattdessen nicken Sie nur einmal am Anfang sämtliche PKGBUILD-Dateien ab, sodass Pacaur dann den (eventuell etwas langwierigen) Build-Prozess ohne weitere Rückfragen in einem Zug abarbeitet. Das spart Zeit und Nerven, da Sie nicht immer wieder ähnliche Fragen lesen und beantworten müssen. Sie installieren Pacaur mithilfe von Yaourt. Anschließend unterscheidet sich die Bedienung des neuen AUR-Helpers in der Regel nicht von jener von Yaourt und eben Pacman (Listing 15). Ein pacaur -Syu sorgt auch hier für das Einspielen aller Updates, egal, ob aus dem AUR oder den herkömmlichen Paketquellen.

$ yaourt -S pacaur
$ pacaur -Ss minecraft
aur/minecraft latest-24 (517)
    An open-world game whose gameplay revolves around breaking and placing blocks
aur/minecraft-server 1.8.6-1 (104)
    Minecraft server unit files, script, and jar
[...]
$ pacaur -S minecraft
:: Paket(e) minecraft wurde in den offiziellen Paketquellen nicht gefunden, suche im AUR...
:: Löse Abhängigkeiten auf...
:: Suche nach Zwischenkonflikten...
AUR Pakete  (1):
Name           Alte Version  Neue Version
aur/minecraft                latest-24
:: Fortfahren mit Installation? [J/n] j
:: Empfange Paket(e)...
:: Betrachte minecraft PKGBUILD? [J/n] j
:: Betrachte minecraft.install Skript? [J/n] j

Aktiv im AUR

Die Zuverlässigkeit des AUR basiert auf dem Mehr-Augen-Prinzip. Je mehr Nutzer aktiv zum AUR beitragen, desto reichhaltiger, aktueller und zuverlässiger entwickelt es sich. Um an diesem Prozess teilzuhaben, müssen Sie keine Programmierkenntnisse besitzen: Ein wichtiger Baustein auf diesem Weg ist Ihre Stimme. Funktioniert ein AUR-Paket problemlos und gefällt es Ihnen, dann geben Sie dem entsprechenden AUR-Eintrag einen “Daumen hoch” – im AUR-Jargon nennt man das eine Vote. Anhand der Stimmanzahl können dann andere Anwender einschätzen, inwieweit das Paket tatsächlich brauchbar ist; zudem besteht die Chance, dass die Software es später in die offiziellen Paketquellen schafft.

Dazu benötigen Sie nichts weiter als einen Account im AUR, den Sie über die AUR-Homepage gesondert von Arch-Forum/Wiki beantragen müssen. Anschließend erweitert die Webseite die mit Package Actions betitelte Box um mehrere Einträge: Mit Vote for this package stimmen Sie wie angesprochen für das Paket, mit Flag package out of date signalisieren Sie dem Paketbetreuer eine neue Version und mit File Request teilen Sie dem AUR-Team mit, dass etwas mit dem Paket nicht stimmt. Alternativ installieren Sie sich aurvote aus dem AUR und stimmen von der Kommandozeile für ein Programm ab (Listing 16).

$ aurvote --configure
Creation of /home/User/.config/aurvote
AUR User : AUR-Konto
AUR Password : Geheim
Persistent login ? [Y/n] y
Path to the cookie file : [/var/tmp/aurvote-User.cookie] ?
Creation complete.
$ aurvote -v google-chrome pacaur
google-chrome : vote changed
pacaur : vote changed

Pacman mit GUI

Nicht jeder Arch-User möchte zum Installieren einer neuen Anwendung oder zum Aktualisieren des Systems ein Terminalfenster öffnen und Pacman-Befehle eintippen – ein grafischer Pacman-Client muss also her. Lassen Sie sich nun nicht davon abschrecken, dass es keine offizielle Pacman-Oberfläche gibt: Die inoffiziellen Lösungen sind aufgrund der Unterstützung der Arch-Derivate Antergos [16] und Manjaro [17] gar nicht mal so schlecht.

Aus der Vielfalt der grafischen Pacman-Aufsätze [18] stechen zwei Anwendungen besonders hervor. Bei PacmanXG [19] handelt es sich um ein altbewährtes Werkzeug, das zum Beispiel bei Antergos zum Einsatz kommt (Abbildung 3). Sie installieren das Programm aus dem AUR über das Paket pacmanxg4-bin. Es weist keine Abhängigkeiten zu GTK oder Qt auf und eignet sich somit besonders für Anwender, die ein schlankes System mit einem reduzierten Fenstermanager bevorzugen.

Abbildung 3: Wer auf ein grafisches Tool für die Paketverwaltung nicht verzichten möchte, der findet in PacmanXG einen zuverlässigen Partner.

Pamac [20] setzt hingegen auf GTK3 auf und bindet sich dadurch sehr gut in Gnome ein (Abbildung 4). Das Programm bietet neben einer aufgeräumten Oberfläche über die in Gnome integrierten Benachrichtigungen auch Update-Hinweise. Pamac dient in Manjaro als Paketmanager und wird auch im Rahmen der Distribution weiterentwickelt, über das Paket pamac-aur installieren Sie die Anwendung jedoch auch auf einem Standard-Arch.

Sowohl PacmanXG als auch Pamac verstehen sich nicht nur bestens mit Pacman, sondern mithilfe von Yaourt auch mit dem AUR.

Abbildung 4: Pamac macht optisch mehr her, benötigt allerdings zahlreiche GTK-Bibliotheken. Der Pacman-Client stammt aus der Arch-Variante von Manjaro.

Fazit

Dieser Artikel kratzt nur an der Oberfläche der Leistungsfähigkeit und Flexibilität der Arch-Paketverwaltung. Machen Sie als Arch-Einsteiger nicht den Fehler, sich von der Komplexität abschrecken zu lassen: Die wichtigsten Pacman-Kommandos gehen nach wenigen Tagen mit der Distribution locker von der Hand, das Vertrauen in AUR-Pakete steigt sehr schnell an. Nach der ersten Eingewöhnung werden Sie die fortlaufenden Updates und die Vielfalt im Arch User Repository nicht mehr missen wollen.