# Pacman Advanced: Die dunkle Seite des Paketmanagements

TL;DR / Management Summary Wer Arch Linux im professionellen Umfeld betreibt, muss mehr können als nur pacman -Syu. In diesem Modul beschäftigen wir uns mit den kritischen Aspekten: Warum Teil-Upgrades das System unbrauchbar machen, wie wir gezielte Rollbacks durchführen, wenn ein Update fehlschlägt, und wie wir eigene lokale Repositories erstellen, um firmeninterne Software standardisiert zu verteilen.

# 1. Einführung & Architektur

Warum Teil-Upgrades tödlich sind.

Arch Linux ist ein “Rolling Release”. Pakete werden gegen die exakten Versionen der aktuell verfügbaren Libraries im Repository gelinkt.

# Das Dependency-Problem (Mermaid)

graph TD
    A[Package: App 1.0] -->|Needs| B[Library: glibc 2.30]
    C[Update: App 2.0] -->|Needs| D[Library: glibc 2.35]
    subgraph "Partial Upgrade Danger"
        E[Admin: pacman -Sy App]
        E -->|Installs| C
        C -->|Tries to find| D
        F[System only has] --- B
        C -.-x|CRASH: Symbol not found| B
    end

# 2. Der perfekte Rollback

Rettung aus dem Cache.

Wenn eine neue Version eines Pakets (z.B. der Kernel oder Treiber) einen Bug hat, können Sie auf die alte Version zurückgreifen, die noch in Ihrem Cache liegt.

# Schritt 1: Alte Version finden

ls /var/cache/pacman/pkg/ | grep nginx
# Output: nginx-1.24.0-1-x86_64.pkg.tar.zst

# Schritt 2: Manuelle Installation

Nutzen Sie das Flag -U (Upgrade/Install from file).

sudo pacman -U /var/cache/pacman/pkg/nginx-1.24.0-1-x86_64.pkg.tar.zst

# Schritt 3: Paket sperren

Verhindern Sie, dass das nächste -Syu den Bug wieder einspielt. In /etc/pacman.conf:

IgnorePkg = nginx

# 3. Eigene lokale Repositories erstellen

Software wie ein Profi verteilen.

Anstatt .pkg.tar.zst Dateien per USB-Stick zu verteilen, bauen wir ein echtes Repo.

# Schritt 1: Repo-Verzeichnis anlegen

mkdir -p /srv/http/arch-repo
cp my-app-1.0-1-any.pkg.tar.zst /srv/http/arch-repo/

# Schritt 2: Datenbank generieren

cd /srv/http/arch-repo/
repo-add custom.db.tar.gz *.pkg.tar.zst

# Schritt 3: In pacman.conf einbinden

[custom]
SigLevel = Optional TrustAll
Server = http://repo.company.local/arch-repo

# 4. Day-2 Operations: Datenbank-Maintenance

Den Index gesund halten.

# Datenbank-Integrität prüfen

sudo pacman -D --check

Dies findet Pakete, die installiert sind, aber deren Abhängigkeiten im System fehlen.

# 5. Troubleshooting & “War Stories”

Wenn pacman lügt.

# Story 1: “Der GPG-Key Teufelskreis”

Symptom: Der Admin will das System updaten, aber pacman meldet für JEDES Paket “Signature is unknown trust”. Ein Update des archlinux-keyring schlägt ebenfalls fehl, da auch dieses Paket nicht verifiziert werden kann. Ursache: Das System ist zu alt (> 6 Monate kein Update). Die Keys sind abgelaufen. Lösung: Deaktivieren Sie die Signatur-Prüfung temporär in der pacman.conf (SigLevel = Never), updaten Sie NUR den Keyring, und schalten Sie die Prüfung sofort wieder auf Required.

# Story 2: “Das volle Dateisystem im Update”

Symptom: pacman -Syu bricht bei 50% ab, weil die Platte voll ist. Das System ist nun in einem inkonsistenten Zustand. Ursache: Fehlende Platzprüfung vor dem Entpacken. Lösung: Booten Sie ein Live-ISO, mounten Sie die Partition, löschen Sie den Cache (rm -rf /var/cache/pacman/pkg/*) und führen Sie pacman --root /mnt -Syu aus, um das Update zu beenden.

# 6. Fazit & Empfehlung

• Rollbacks: Löschen Sie niemals den gesamten Cache. Behalten Sie mindestens die letzten 2 Versionen.
• Custom Repos: Nutzen Sie lokale Repos für alle Pakete, die Sie im AUR bauen, um sie auf mehreren Servern zu verteilen.
• Wahl: Pacman ist ein Werkzeug für Fortgeschrittene. Wer die Regeln (keine Teil-Updates!) missachtet, wird scheitern.

# Anhang: Cheatsheet