Alternatively, we could get the Nix store paths directly from http://releases.nixos.org/?prefix=nix without going through the Hydra evaluation ID, but the binary blobs seem to be detached from their original store paths, so that's also not doable.

I'm wondering whether these fallback paths could just get a statically linked Nix from releases.nixos.org and import it as a CA path. That would avoid having to pull in stuff from hydra (releases.nixos.org doesn't have the static builds yet, but it wouldn't be hard to add them, and it would probably be good any way)

IMHO it's a bit silly to have an update script for something that already gets output by the release script. Maybe it would help if the release script uploads the new fallback paths to the S3 bucket?

@edolstra It should be the Hydra evaluation ID used for the release instead

The release script now uploads fallback-paths.nix, see e.g. https://releases.nixos.org/nix/nix-2.16.1/fallback-paths.nix.

@edolstra Why not the hydra evaluation ID? It doesn't make sense for the Nix release script to generate a Nixpkgs-specific file..

Because it's much more convenient to do it this way.

@edolstra I do not agree about that. I opened NixOS/nix#8464 with my suggested solution instead, please take a look.