Perhaps we need to need to develop a retention policy over the next year, that spells out clearly which derivations must always be kept and which can be deleted after a certain period of time.
Here’s an example policy:
Easy wins for deletion:
- NixOS Release ISOs/RPi SD images/Virtualbox VHDs - They can be trivially rebuilt from other cached packages, take up space with duplicate content, and are rarely if ever substituted from cache.
- In the long term, we could consider a
dockerTools-like streamed image approach that doesn’t put the final image into the store at all.
- In the long term, we could consider a
- Unreachable binaries for older (N-2?) releases of NixOS - These should be very rarely requested, and we can still keep the metadata and checksums to aid in statistics generation and future research.
Paths to never delete:
- Sources for software. These generally don’t change as often as the binaries built from them, so shouldn’t be as expensive to cache.
- Going forward, we can be smarter about how we link in git submodules to sources, e.g.
qtwebengineis 15mb but submodules pull in more than 2gb of chromium source. see: What should the Hydra output size limit be? - #17 by rnhmjoj
- Going forward, we can be smarter about how we link in git submodules to sources, e.g.
- Patches. Most patches should exist in the nixpkgs repo, but there’s likely patches that were pulled with
fetch*functions at some point and I’m not sure how one would disambiguate them.