Automatic Cache Purge vs. Static Binary Set for Spack Buildcache in Low‑Traffic HPC Workloads

The goal is to minimize compute and network costs for a low‑traffic HPC workload by leveraging Spack’s binary cache (buildcache) and local mirror.

When the binary cache is populated, administrators must decide whether to let Spack automatically purge old spec entries or to maintain a static set of binaries that persists across package variant changes or upstream patches. This decision influences storage usage, the risk of running stale binaries, and the frequency of cache misses that fall back to the mirror or external repositories.

What are the trade‑offs between automatic purging of old spec entries and retaining a static set of binaries? How does each policy affect build time, storage consumption, and the likelihood of API incompatibility? Which policy better suits workloads with infrequent changes and limited storage?