cave¶
Note
Paludis / cave is slow-moving: its last release (3.0.2) and commits date to around March 2025, though the project is not archived and carries no retirement notice.
- ID
cave- Home page
- Platforms
🐧 Linux (Exherbo Linux only)
- Operations
installed·orphans·install·upgrade·upgrade_all·remove·sync·cleanup- purl types
pkg:cave- CLI name
cave- Every call
cave --colour no <command>- Issues and PRs
- Source
cave is the client of Paludis, Exherbo’s package mangler (https://paludis.exherbo.org).
Parsing notes, verified against the cave man pages (paludis.exherbo.org/clients/):
print-idsis the only machine-parseable listing (“No formatting is used, making the output suitable for parsing by scripts”), with a caller-controlled--format; the ‘/::installed’ spec selects the installed repository.No
search:cave searchemits multi-line human records with no format control, andprint-ids --matchingneeds an exact spec rather than a fuzzy query. Nooutdatedeither: thecave resolveplan is human-oriented.resolvenever prompts (it refuses risky transactions instead, wanting explicit--permit-*flags), so no assume-yes flag exists or is needed.Execute phases (
--execute) and sync need root; plan-only and print-ids calls do not.
What mpm adds to cave¶
mpm reaches across every manager at once, not cave alone: mpm installed and mpm outdated cover cave alongside every other manager you run in one table, mpm upgrade --all updates them together, and mpm sbom exports the whole machine as one bill of materials.
Every mpm command also gains --dry-run and --plan previews, cross-scheme version comparison and purl identifiers. See manager augmentations for how each one is built.
Your cave commands, in mpm¶
You already know cave: each operation maps one-to-one onto mpm, in an interface shared by every manager.
To… |
With |
With |
|---|---|---|
List what’s installed |
|
|
Install a package |
|
|
Upgrade one package |
|
|
Upgrade everything |
|
|
Remove a package |
|
|
List orphaned dependencies |
|
|
Prefix any command above with --dry-run to simulate the underlying manager calls without touching the system: the safe way to watch what mpm would do before trusting it.
Operations¶
Operation |
Supported |
Notes |
|---|---|---|
|
✓ |
|
|
||
|
✓ |
|
|
||
|
✓ |
|
|
✓ |
|
|
✓ |
|
|
✓ |
|
|
✓ |
|
|
✓ |
|
|
Selecting and configuring cave¶
Deselect cave for a single run with --no-cave, or persist the choice in your configuration:
[mpm]
cave = false
The arguments and environment variables listed in the box atop this page are forced on every cave call, so runs stay quiet, non-interactive and reproducible: the defaults you would set in CI anyway.
Keep it enabled but tune how mpm drives it with a per-manager override:
[mpm.managers.cave]
timeout = 900
mpm config-template cave prints every overridable attribute as a ready-to-paste block.
Recipes¶
A few jobs you would otherwise script around cave, one mpm command each:
Snapshot and clone a machine:
mpm --cave dump cave.toml, thenmpm restore cave.tomlon the next one.Export a compliance SBOM:
mpm --cave sbom(CycloneDX by default,--spdxfor SPDX).
Privilege escalation¶
System-wide manager: mpm wraps its privileged operations in sudo out of the box. Instead of letting the tool prompt mid-run, mpm primes the credential cache up-front, with a single branded password prompt at most. Turn escalation off for rootless setups with --no-sudo or the per-manager sudo override.
Root is required for its cleanup_orphan, install, remove, sync, upgrade, upgrade_all operations.
See privilege escalation for the full policy.
Cooldown¶
State of cave’s release-age gating, from the cooldown support table:
Status: ❌ None (Exherbo, source-based)
A cooldown only pays off where a compromised release can be withdrawn while the clock runs, and can only be emulated where the registry dates its releases. From the retraction table:
Registry: Source-based recipe trees
Retraction: Index revert of the recipe tree
Publish date: ❌ a recipe carries no publication date
With --cooldown set, mpm skips this manager’s install and upgrade operations rather than run them unguarded (fail-closed); --allow-unsupported-managers opts back in.
Version probe¶
The version is probed by running:
$ cave --version
cave 3.0.1
and extracted with:
r"(?P<version>\d+\.\d+\.\d+)"
Reference traces¶
Raw native outputs captured in the bundled definition: the reference mpm’s parsers were written against. If you know cave well and a transcript below looks wrong, or a newer release changed its output format, report it.
$ cave print-ids --matching */*::installed --format %c/%p %v\n
app-arch/gzip 1.14
sys-apps/sed 4.9
$ cave purge
Done: 156 metadata, 42 steps
These are the actions I will take, in order:
< dev-libs/libpcre-8.45:0::installed
Reasons: purge
< app-misc/tmux-3.3a:0::installed
Reasons: purge
Total: 2 uninstalls
Use --execute to perform the actions I described.
Feed any of these through mpm and the raw output becomes one uniform table, the same shape for every manager: filter it, project columns, or export it (mpm --cave installed --output json, or csv, toml, yaml), each package carrying a purl and a version comparable across managers.
Changelog¶
7.4.0(2026-07-25)Their cleanup commands, both orphan sweeps (
cave purge,pkg_delete -a), are re-declared ascleanup_orphan:cleanup --orphansnow reaches them andcleanup --cacheleaves them alone.Plain
cleanupno longer removes orphaned packages: their native sweeps moved behindcleanup --orphans. This also stopsemerge’s cleanup from triggering its pre-depclean world upgrade unless--orphansis given.
7.2.0(2026-07-09)Add cave (Exherbo’s Paludis client) with
installed,install,upgrade,remove,syncandcleanupsupport; a bundled configuration-defined manager.