# Pacman Paketcache verwalten (paccache)

Pacman lädt jedes Paket als `.pkg.tar.zst` nach `/var/cache/pacman/pkg` und **löscht es danach
nicht mehr**. Der Cache wächst dadurch unbegrenzt – auf diesem System waren es einmal 66 GB,
was den Plattenplatz deutlich stärker belegte als der gesamte AUR-Cache (`~/.cache/yay`).

Mit `paccache` (Paket `pacman-contrib`) lässt sich das steuern.

---

## Wo liegt der Cache?

Standardpfad ist `/var/cache/pacman/pkg`. Wird in `/etc/pacman.conf` kein `CacheDir`
gesetzt, gilt dieser Pfad:

```bash
# Konfiguration prüfen
grep -E '^CacheDir' /etc/pacman.conf
# nicht gesetzt → Standard /var/cache/pacman/pkg

# Aktuelle Größe (root-owned, daher sudo nötig)
sudo du -sh /var/cache/pacman/pkg
```

> **Achtung:** Der Pacman-Cache liegt **nicht** unter `~/.cache/pacman`. Er gehört dem
> System und braucht `sudo`. `~/.cache/pacman` existiert auf Arch normalerweise nicht.

---

## paccache: Optionen

*paccache v1.13.1*

**Operationen** (was passieren soll):

| Option | Bedeutung |
| --- | --- |
| `-d, --dryrun` | nur Kandidaten finden, **nichts löschen** |
| `-r, --remove` | Kandidaten löschen |
| `-m, --move <dir>` | Kandidaten nach `<dir>` **verschieben** statt löschen |

**Optionen** (wie ausgewählt wird):

| Option | Bedeutung |
| --- | --- |
| `-k, --keep <num>` | nur die `<num>` neuesten Versionen pro Paket behalten (**Default: 3**) |
| `-u, --uninstalled` | nur Pakete, die derzeit **nicht** installiert sind |
| `-c, --cachedir <dir>` | zu durchsuchendes Verzeichnis (Default: aus `/etc/pacman.conf`) |
| `--min-atime <zeit>` | Pakete behalten, die jünger als `<zeit>` sind – unabhängig von `-k` |
| `--min-mtime <zeit>` | dito, anhand des Änderungsdatums (zuverlässiger, siehe unten) |
| `-i, --ignore <pkgs>` | Paketnamen ausschließen (Komma-separiert) |
| `-v, --verbose` | ausführlicher, bis `-vvv` |
| `-q, --quiet` | Ausgabe reduzieren |
| `-f, --force` | entspricht `rm -f` / `mv -f` |
| `-z, --null` | null-Trennzeichen in der Ausgabe (nur mit `-v`/`-vv`) |
| `--nocolor` | keine Farbformatierung |

> **Achtung, Default:** Ohne `-k` behält `paccache` **3** Versionen pro Paket. Wer
> gezielt reduzieren will, muss `-k` explizit setzen.

Die beiden wichtigsten Aufrufe:

```bash
# Vorschau: 2 neueste Versionen behalten
sudo paccache -rk2 -v

# Ausführen
sudo paccache -rk2
```

### Sicherster Testlauf erst verschieben, dann löschen

Statt direkt zu löschen kann man Kandidaten in ein Sammelverzeichnis verschieben und
erst nach Prüfung endgültig entfernen:

```bash
sudo paccache -m /tmp/pacman-cache-backup -rk2
du -sh /tmp/pacman-cache-backup
# nach Kontrolle:
rm -rf /tmp/pacman-cache-backup
```

### `--min-atime` vs. `--min-mtime`

Diese Optionen durchbrechen das `-k`-Limit: alles, was jung genug ist, bleibt erhalten.
Auf einem **`noatime`**-Mount ist `--min-atime` jedoch unzuverlässig, weil Lesezugriffe
die Zugriffszeit nicht mehr aktualisieren – dort misst atime faktisch nur den letzten
Schreibzugriff. In dem Fall `--min-mtime` verwenden. Siehe
[[IT-Know-How/Linux/BASH Basics/find]].

### Gemessene Einsparung (System dieses Nutzers, 66 GB Cache)

| Aufruf | Kandidaten | Freier Speicher |
| --- | --- | --- |
| `paccache -rk2` (2 Versionen behalten) | 4332 | **40,3 GiB** |
| `paccache -ruk0` (nur installierte behalten) | 99 | 12,8 GiB |
| `paccache -rk0` (nichts behalten) | 7153 | 65,7 GiB |

**Empfehlung: `-rk2`.** Es erhält zwei Versionen pro Paket und damit die Möglichkeit,
ein Update zurückzunehmen. `-rk0` ist maximal gründlich, lässt aber kein Downgrade zu –
bei einem defekten Update dann nur noch der Weg über das Archiv.

> `-duk0` entfernt ausschließlich Pakete, die gar nicht mehr installiert sind – z. B.
> Rückstände nach `pacman -R`. Das ist die unkritischste Variante.

### Downgrade statt löschen

Solange die `.pkg.tar.zst` im Cache liegt, funktioniert ein Downgrade direkt:

```bash
sudo pacman -U /var/cache/pacman/pkg/paket-1.0.0-1-x86_64.pkg.tar.zst
```

Genau deshalb ist `-k 2` sinnvoller als `-k 0`.

---

## Automatisch aufräumen: paccache.timer

`paccache` bringt bereits einen **Systemd-Timer** mit, der auf diesem System
vorinstalliert, aber **deaktiviert** ist:

```bash
# Status prüfen
systemctl is-enabled paccache.timer     # → disabled
systemctl list-timers paccache.timer
```

Einrichtung:

```bash
# 1. Timer aktivieren (läuft dann wöchentlich)
sudo systemctl enable --now paccache.timer

# 2. Verhalten festlegen: 2 Versionen behalten
sudo sed -i 's/^PACCACHE_ARGS=.*/PACCACHE_ARGS="-rk2"/' /etc/conf.d/pacman-contrib

# 3. Einmalig sofort ausführen
sudo systemctl start paccache.service

# 4. Nächsten Laufzeitpunkt ansehen
systemctl list-timers paccache.timer
```

Die Argumente kommen aus der Environment-Datei `/etc/conf.d/pacman-contrib`:

```bash
# Standard: leer
PACCACHE_ARGS=
```

Wird sie nicht gesetzt, verwendet der Service nur `paccache -r` (Standardverhalten des
Tools). Deshalb lohnt sich das Setzen auf `-rk2`.

Der Service ist bereits sinnvoll vorkonfiguriert – `Type=oneshot`, `Nice=19`,
`CPUSchedulingPolicy=idle` sowie diverse Härtungsoptionen (`ProtectSystem=full`,
`ProtectHome=yes`, `NoNewPrivileges=yes`, …). Die Cache-Bereinigung läuft also mit
niedrigster Priorität und blockiert keine interaktive Arbeit.

`Persistent=true` ist im Timer gesetzt: War der Rechner ausgeschaltet, wird die
aufgeholte Ausführung beim nächsten Start nachgeholt.

### Rhythmus ändern

Standard ist `OnCalendar=weekly`. Für einen selteneren Durchlauf einen Drop-in anlegen:

```bash
sudo systemctl edit paccache.timer
```

```ini
[Timer]
OnCalendar=
OnCalendar=monthly
```

Die **leere** `OnCalendar=` ist wichtig: sie setzt die vorhandene Liste zurück, sonst
hätte das System beide Zeitpläne (weekly *und* monthly) parallel.

Danach:

```bash
systemctl cat paccache.timer      # Drop-in prüfen
systemctl list-timers paccache.timer
```

---

## Warum kein Cron?

Für diese Aufgabe ist ein Cronjob die schlechtere Wahl:

1. **Root ohne interaktive Passwortabfrage.** Der Job bräuchte `sudo` im Befehl.
   Ein `sudo`-Prompt in einer Cron-Umgebung schlägt still fehl – der Job sieht aus, als
   liefe er, passiert aber nichts. Bei einem User-Cron zusätzlich: Cron läuft ohne
   volles Terminal, `sudo` kann die Passwortabfrage oft nicht darstellen.
2. **Die systemd-Unit existiert bereits.** Sie ist sandboxed, priorisiert und
   `Persistent`. Das in Cron nachzubauen hieße, es schlechter zu machen.
3. **Ausgabe geht verloren.** Bei `journalctl -u paccache.service` ist nachvollziehbar,
   was gelöscht wurde – bei Cron nur in Logdateien.

Als Faustregel: **Was eine Aufgabe als Root und/oder regelmäßig braucht → systemd-Timer.
Was als normaler User und unregelmäßig läuft → Cron oder `systemd-run --user`.**

Für den AUR-Cache ist Automation ohnehin unnötig: `yay -Sc` räumt ihn auf, und er
belegt nur noch ~100 MB. Siehe [[IT-Know-How/Linux/yay Cache reparieren]].

---

## Siehe auch

- [[IT-Know-How/Linux/yay Cache reparieren]] - AUR-Cache, `.git`-Korruption durch Cleanup
- [[IT-Know-How/Linux/Paketinstallation in Linux-Distributionen]] - pacman/yay Grundbefehle
- [[IT-Know-How/Linux/BASH Basics/find]] - sichere `-delete`-Kommandos für Cache-Aufräumen