Thank you so much for the code sample. This is the sort of thing that I understand in principle, but would take me a prohibitive amount of time to sort out the details in practice.
One thing that has me stymied: I get the error
error: hash mismatch in file downloaded from 'https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.12/hdf5-1.12.2/src/hdf5-1.12.2.tar.bz2':
specified: sha256:181bdh8hp7v9xqwcby3lknr92lxlicc2hqscba3f5nhf8lrr9rz4
got: sha256:1zlawdzb0gsvcxif14fwr5ap2gk4b6j02wirr2hcx8hkcbivp20s
while the code that I copy-pasted from your example contains
url = "https://support.hdfgroup.org/ftp/HDF5/releases/hdf5-1.12/hdf5-1.12.2/src/hdf5-1.12.2.tar.bz2";
sha256 = "sha256-5OeUM0UO2uKGWkxjKBiLtFORsp10+MU47mmfCxFsK6A=";
The URLs match, but the specified
(or even the got
) SHA in the error message does not match the one specified in the code.
Oh … your code did not qualify fetchurl
and I guessed that it comes from builtins
, which is what resulted in the above error message. But there is also a fetchurl
in nixpkgs
. If I use that one instead, I now get
specified: sha256-5OeUM0UO2uKGWkxjKBiLtFORsp10+MU47mmfCxFsK6A=
got: sha256-Goi742ITos6gyDlyAaRZZD5xVcnckeBiZ1s/sH7jiv4=
that is to say, the specified
SHA in the error message now does match the one specified in the source.
This leaves me with two puzzles:
-
WTF is the difference between
builtins.fetchurl
andnixpkgs.fetchurl
? OK, I’ve found this, but I don’t have time to ruminate on it and to try to digest its meaning. It’s tempting to conclude that it’s an evil practical joke. These sorts of things certainly don’t help wider adoption of Nix. -
If the URLs match exactly, but the SHAs differ, I infer that they update the tarball at that location (or a miscreant is up to something nefarious), and if they do that then this derivation is going to be running into this problem repeatedly. If so, is there a workaround?