/cc @edolstra.

I don't understand why this should be reverted, isn't that what staging is for?

@domenkozar: the claim is that it would require us to rewrite all the hashes in sources.

@domenkozar The value of sha256 in fetchurl and all other fetch functions depends on name (which by default is computed from the URL). So if you change the name, you have to recomputesha256, or nix-build will exit with e.g.

output path _/nix/store/arsizl1pa5ch8d6wgh49x8vvbfb9qyz1-source_ has r:sha256 hash _03wd1qvkrj50fjszb2apzdkc8d5bpfbbi9pajl0vbrlzzmmi3jlq_ when _0636absdfjx8ybglwydmqxwfwmqz1c4b9s5mhxlgm4ci18lw3hms_ was expected

That commit changed names of all fetch derivations without updating their hashes.

This is incorrect. The output hash does not depend on name. The store path does, but changing the store path should not be a problem.

For example, building nix-repl.src with name set to foo or bar respectively gives store paths:

/nix/store/gbxjginw6h789qp5xk9m788zqrgc43ms-foo
/nix/store/hbz2r8m1czcsfjg6yvn27263zgks3gwm-bar

without requiring a change to the outputHash.

Do you have an example of a particular package that fails to build?

@orivej I suspect you'll also get the same hash mismatch if you force a rebuild of the sources.
This sometimes happens if upstream changed something in the tarball or when the hash was updated incorrectly at some point.

nix-build -A hello.src --check

I think Hydra will discover the failing fetches soon on staging, and we'll have to fix those individual hashes. Probably hunspell and lua failures from here: https://hydra.nixos.org/eval/1406150?compare=1406145#tabs-now-fail

@LnL7 Indeed. The rebuild failed with hash mismatch, I knew that the hash in the nix store depends on derivation name, but I did not consider that it may be computed from the specified sha256 value rather than actual contents.

@edolstra

Do you have an example of a particular package that fails to build?

The 0636abs… mismatch is from luaPackages.luastdlib.src. Apparently release.zip is a link to the latest GitHub release. I've fixed it in #31031.

Still, the motivation for c3255fe is not clear to me. How is that useful? Readable names in nix store are definitely desirable (e.g. a860360) — I would not like to turn /nix/store/hash-name/ into /nix/store/hash/ neither for all derivations nor just for sources.

@orivej For the motivation, see Domen's NixCon talk. We currently have 5 different names/store paths generated for the same tree (in builtins.fetchTarball, builtins.fetchGit, Nixpkgs nix-prefetch-git, Hydra nix-prefetch-git, or using ./.). Thus, for example, the same tree built via builtins.fetchGit ./. will produce a different store path than when built by Hydra. This patch is part of making them the same.

The original commit is now in master, though some fallback hasn't been resolved yet. Some of it are just uncovering of force-updated git tags upstream and similar stuff, some are packages assuming that the name of the source has a particular format – with some special cases where you have multiple sources and thus get a new name collision during unpacking (example: dmd).

Having the less descriptive name is a disadvantage. Perhaps in future we could devise a nicer scheme for default naming that's also consistent among all the fetching mechanisms...

For the motivation, see Domen's NixCon talk.

For the record, Domen's talk is here and the slides are here (slide 8).

For what it's worth, this does actually have a nontrivial effect on some derivations. Most notably for me are image builds, which actually care about the store path in question to inject a channel into the image being built. Not a big deal, but it was confusing for a bit 😄

c3255fe seems to break pkgs.python35Packages.tensorflowWithCuda; haven't investigated yet, but filed #31828