# paccache, orphans and the Arch package cache

> Arch never removes an old package on its own, by design, because downgrading is part of the deal. How to keep the number of versions you actually need and clear the rest, plus orphans and the AUR build cache.

Canonical: https://bytesweep.app/blog/pacman-cache-cleanup.html
Last updated: 2026-10-27

## Keeping the Arch package cache useful instead of enormous

pacman never deletes a package it has downloaded. Every version of everything you have installed stays in `/var/cache/pacman/pkg`, and that is deliberate: on a rolling release, going back to yesterday’s version of a package is a normal way to get out of trouble. After a year of daily updates the directory is often 20 to 60 GB, and the part worth keeping is the last one or two versions of each package.

- By [Shajeen Ahamed](https://bytesweep.app/about.html#author)
- Published 27 October 2026
- Last updated 27 October 2026
- 2 min read
- Part of [Disk usage analyzer for Linux](https://bytesweep.app/linux-disk-usage-analyzer.html)
- [How we write](https://bytesweep.app/about.html#how-we-write)

```
du -sh /var/cache/pacman/pkg
ls /var/cache/pacman/pkg | wc -l
```

A count in the thousands, or tens of thousands after a year or two, is normal. The size comes from a few packages that are both large and frequently updated: the kernel, `linux-firmware`, browsers, anything built against a fast-moving toolchain. `linux-firmware` surprises people. It carries firmware for every supported device, not just yours, so a handful of cached versions is gigabytes on its own.

### Use paccache, not rm

`paccache`, from `pacman-contrib`, understands versions, which `rm` and a glob do not:

```
sudo pacman -S pacman-contrib

paccache -d                # dry run: show what would be removed
sudo paccache -r           # keep the 3 most recent versions of each package
sudo paccache -rk1         # keep 1
sudo paccache -ruk0        # remove all cached versions of uninstalled packages
```

*Run -ruk0 first for packages you no longer have, then -rk2 or -rk1 for the ones you do.*

Start with `-ruk0`. A package you no longer have installed needs no downgrade path, so that one is free. Then choose `-rk2` or `-rk1` for everything else. I would keep two: the installed version and one to fall back to. One is fine if you have a fast connection, because nothing is ever truly lost: the Arch Linux Archive at `archive.archlinux.org` holds historical packages, slower to reach than a local cache but always there.

pacman’s own options are blunter:

| Command | Effect | Verdict |
| --- | --- | --- |
| `pacman -Sc` | Removes uninstalled packages' caches and unused sync dbs | Reasonable |
| `pacman -Scc` | Removes everything, including the current versions | Leaves you unable to downgrade or reinstall offline |
| `paccache -rk1` | Keeps one version of each installed package | The sensible default |

### Make it automatic

`pacman-contrib` ships a timer that runs `paccache -r` once a week:

```
sudo systemctl enable --now paccache.timer
```

To keep a different number of versions, override the service:

```
sudo systemctl edit paccache.service
## [Service]
## ExecStart=
## ExecStart=/usr/bin/paccache -rk2
```

Some people prefer a pacman hook in `/etc/pacman.d/hooks/paccache.hook`, which cleans up straight after each upgrade instead of on a schedule. Either works.

### Orphans

These are packages that were installed as dependencies and that nothing requires any more:

```
pacman -Qtdq                                  # list them
sudo pacman -Rns $(pacman -Qtdq)              # remove them, configs included
```

`-Rns` removes each package, the dependencies it no longer needs, and its configuration files. Read the list first. A package counts as an orphan only because nothing declares it as a dependency, so something you installed on purpose and later marked as a dependency by mistake will show up there.

With an empty orphan list, `pacman -Rns $(pacman -Qtdq)` errors and does no harm. With a surprising list, it removes things you wanted. Look at `pacman -Qtdq` every time.

### The AUR helper’s cache

An AUR helper keeps sources and built packages of its own, in a directory it chooses, and `paccache` does not know about it:

```
du -sh ~/.cache/yay ~/.cache/paru 2>/dev/null
yay -Sc
paru -Sc
```

For anything built from a large source tree (a browser, a toolchain, a project with vendored dependencies) this directory is often larger than the pacman cache itself.

Beyond packages, Arch fills up the same way as any distribution: the journal ([bounding the systemd journal](https://bytesweep.app/blog/journalctl-vacuum.html)), `/var/log` (logrotate and what grows there), and Flatpak if you use it (unused Flatpak runtimes). The order to work through a full root volume is in [the first five commands](https://bytesweep.app/blog/linux-disk-full-root.html).

### See all of this on your own disk

Every path on this page is one Bytesweep already knows by name. It measures the whole disk in about ten seconds, shows what is safe and what is not before you touch it, and moves everything it removes to a restore point you can undo for seven days.

[Download Bytesweep free](https://bytesweep.app/download.html) [Buy · $29.99](https://bytesweep.app/pricing.html)

### Keep reading

- [**apt caches, old kernels and what autoremove actually purges** On Debian and Ubuntu the reclaimable space is in three places, and only one of them is the package cache. The commands in order of return, and why purge and autoremove are not the same thing.](https://bytesweep.app/blog/apt-cache-cleanup.html)
- [**/ is full on Linux — the first five commands to run** A full root file system takes down services before it takes down your desktop. The order to diagnose it in, the deleted-but-open-file trap that hides gigabytes, and what is safe to remove on any distribution.](https://bytesweep.app/blog/linux-disk-full-root.html)
- [**The systemd journal is bigger than you think: bounding it** journald defaults to using up to ten per cent of the file system, capped at 4 GB, and nobody chose that number. How to see the real size, vacuum it safely, and set a permanent cap that survives reboots.](https://bytesweep.app/blog/journalctl-vacuum.html)