[Issue]: Every SDK install leaves the previous one on disk, with no way to see or reclaim the space

[rominf]

Problem Description

Every SDK install that resolves to a new version creates a fresh multi-gigabyte tree, and nothing ever removes the old ones. There is no retention limit, no cleanup, and no command to reclaim the space — so a machine that installs or updates the SDK a few times fills up.

runtime_key() (apps/rocm/src/therock.rs:3071) folds the version into the key, and both install formats always supply one:

• wheel: apps/rocm/src/therock.rs:806-811 passes Some(&resolution.latest_version)
• tarball: apps/rocm/src/therock.rs:1020-1024 passes Some(&artifact.version)

managed_runtime_root() (apps/rocm/src/therock.rs:3085) then derives data_dir/runtimes/<format>/<key>, so a new upstream version means a new root and, for wheel installs, a whole new virtual environment with its own copy of the ROCm SDK and the torch stack. The version-less branch of runtime_key is unreachable in production — the only caller that omits a version is a unit test.

Side-by-side installs are deliberate (runtime_key_includes_version_for_side_by_side_installs asserts it), and that is a reasonable design. The gap is that nothing bounds how many accumulate. rocm update --apply goes through the same install path, so simply keeping up to date is the main way users hit this.

The only pruning anywhere in the codebase is log files (apps/rocm/src/logging.rs:115, keeping 7) and dash demo sessions (apps/rocm/src/dash.rs:267). There is no cache, prune, clean, or gc verb anywhere in the command tree, and rocm uninstall is all-or-nothing rather than incremental.

There is also no way to see what is using the space. rocm examine reports installs but not their size, so a user who is running out of disk has nothing to act on.

Steps to Reproduce

1. Run an SDK install.
2. Later, run it again (or rocm update --apply) once a newer version is published.
3. Both versions remain on disk in full. Repeat as versions are released; nothing is ever reclaimed.

Suggested Fix

Two capabilities, matching the shape of the existing rocm runtimes / rocm services subcommands:

See it. A disk-usage report covering managed runtimes (per install, with size and whether it is active), the ROCm CLI cache, and — clearly labelled as shared with other tools — the uv cache and the model cache. Read-only, with a --json form like rocm examine --json.

Reclaim it. Prune old runtimes with a retention policy (keep the N most recent per channel/format/family), plus a way to drop cached archives that can be re-fetched. --dry-run and --yes throughout, mirroring rocm uninstall.

Safety rules the implementation needs to respect:

• Never remove the active runtime, the previous runtime (rocm runtimes rollback depends on it), or the configured default.
• Never remove a runtime the user only adopted or imported — should_remove_runtime_install_root (apps/rocm/src/main.rs:5930) already refuses when read_only or imported_from is set and requires a matching in-tree manifest, so prune should reuse it rather than reimplement removal.
• Keep the existing path guards (runtime_install_root_is_protected, crates/rocm-core/src/runtime.rs:365). These matter more here than for a targeted uninstall, because prune acts on a set the user did not enumerate.
• Group retention by family, so a multi-GPU machine can legitimately keep one runtime per family.

Worth a maintainer opinion: what the default retention should be (keeping the current plus one rollback target seems the natural floor), and whether rocm update --apply should offer to prune what it superseded, since update is what drives the accumulation.

Additional Information

Found while investigating unbounded disk growth. Companion issues cover cached tarball retention, uninstall not reaching the shared caches, and the free-space preflight.