Manual cache clearing versus automatic evaluation cache invalidation for managing rebuild speed in NixOS

Goal: Determine whether to rely on manual garbage collection or on the automatic Nix evaluation cache (with flake‑based input locking) to keep nixpkgs up to date while minimizing rebuild time and controlling disk usage.

Constraints: Manual clearing guarantees that stale derivations are removed, ensuring fresh evaluations, but it forces a full rebuild of affected packages and temporarily increases store size. Automatic cache reuse speeds up evaluation when the underlying nixpkgs source has not changed, yet the cache key may omit host‑toolchain details (e.g., glibc version), allowing stale or incompatible binaries to be considered substitutable and potentially breaking rollback safety if needed derivations are GC’d too aggressively.

Uncertainty: How often manual GC should be run to balance rebuild speed against rollback preservation, what evaluation‑cache size and auto‑optimise settings provide sufficient hit ratios without retaining stale entries, and whether combining periodic GC with flake input locks yields a stable trade‑off for typical development workflows.

Questions: What GC frequency yields acceptable rebuild times without compromising the ability to roll back to recent generations? How do specific max‑size and auto‑optimise values affect cache hit ratio versus the risk of using stale derivations? Does a scheme that locks flake inputs and runs occasional GC reliably keep nixpkgs evaluation current while bounding disk growth?