I am not interested in packaging it for anyone, but I want to keep my yuzu build around and make sure it doesn’t get garbage-collected. Will leaving yuzu in my package list cause a problem at some point, or is that sufficient?
1 Like
It needs to get rebuild when one of the dependencies change, so you’ve got essentially four options:
- Pin Nixpkgs and use Yuzu from that pinned version. It shouldn’t be GC’d as long as it is in your system closure and no rebuilds should occur due to pinning.
- Fork the source to a private repo and override the Yuzu package to use your source
- copy the closure of
yuzu.srcto a safe place so you can re-import it in case it is GC’d and required for a new build (effectively a source backup) - copy the closure of Yuzu itself to a safe place so you can re-import on another system, won’t let you rebuild but should give a working binary backup
5th option:
- remove it from your system closure, add it directly as a manual gc root, and use it via the store path explicitly, or add a symlink somewhere in your path (which won’t get invalidated because it won’t get rebuilt).
but probably keeping a private repo is the best long-term option
2 Likes
You can load the store path into a profile, which will keep the package from being gc’d and also a place to access it.
nix-env --profile ~/yuzu --install $(readlink -e $(which yuzu))
1 Like