I’m not sure that exactly what you want is possible, I certainly don’t think it’s trivial though.
That said, is your goal to avoid “overwriting” what you sync from the build server? If so, consider the following:
- The nix store paths are by definition unique; locally built packages can never overwrite what’s in there already. You should not need to worry about sharing that nix store whatsoever, just rsync-ing in the remote paths (and not overwriting local ones) should never cause issues and in fact reduce disk wear, speed up transfers and waste less energy.
- Rather than doing manual rsyncs, have you considered using your build machine as a remote cache? It’s really easy to set up. Your local host will just grab whatever the remote builder has previously built and put it in your local cache. The only downside is that you’ll need an active connection to the server whenever you want to use its cache, but if both machines are local that’s pretty easy (and you can still do an rsync whenever you think you might be without a direct connection for a while).
@Solene has nice blog posts on cache hosting or using peerix
- Also, if you want to keep your private keys outside the cache, use something like sops-nix. I remember that @Solene asks for suggestions on that in the peerix blog post, never gotten around to emailing about that
Spongix may be a nice candidate for local caching remote derivations from caches + your built derivations GitHub - input-output-hk/spongix: Proxy for Nix Caching
@TLATER @Solene My use case is an offline (and not powerful) machine. Should have mentioned that, sorry. So the idea is, on a monthly basis I get a fresh large
/nix/store copied over from a powerful online machine - but locally I also want to benefit from keeping the nix builds that I built offline (and not losing them after the next monthly copy).
In that case, why would you lose the old store contents during the copy?