-
-
Notifications
You must be signed in to change notification settings - Fork 15k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
util-linux: 2.27.1 -> 2.28 #15048
util-linux: 2.27.1 -> 2.28 #15048
Conversation
By analyzing the blame information on this pull request, we identified @edolstra, @nckx and @wkennington to be potential reviewers |
Oh, I haven't noticed you switched to sha512. That seems unfortunate, for such a core package, at this point. I fear it will cause evaluation errors for many people. Now it's in master. Changing hash type is always a mass rebuild, unfortunately. |
It's fine to upgrade NIx in master, let's bump |
In general I think it would be nice if at least the nix package could be evaluated (and built, including its closure) by relatively old Nix versions. The way we abort actually seems to go contrary to that. |
+1 for a bit of backwards compatibility here (allowing old nix to evaluate newer nixpkgs). |
Is it possible to specify both sha256 and sha512 hashes? From my understanding, fetchurl will simply use the strongest hash; I'm not sure if it will ignore hash types it doesn't know about. |
Why would this be a problem, util linux is not a dependency of nix or On Fri, May 13, 2016, 7:57 AM Aneesh Agrawal notifications@github.com
|
No, util-linux isn't in (build-time) closure of nix. The problem would arise if we now bumped
That won't help much. Changing hash type has to cause a rebuild, at least unless we make principal changes in nix itself. |
@vcunat fetchurl already picks the strongest hash. We can change fetchurl so that it only tries to use hash types that the current Nix version supports. In that case, supplying both sha256 and sha512 hashes to fetchurl allows old and new Nixs to evaluate the derivation: Proposed changes to fetchurl would do this when both sha256 and sha512 are specified:
I'm OK with causing rebuilds when we use a stronger hash type, my main concern is backwards compatibility. I can put in a PR to make fetchurl work like this (instead of throwing an assert) if this sounds OK. |
We could change it, but backwards compatibility seems of less use when you can't share any depending binaries. |
Instead of requiring that Nix be new enough to handle the sha512 hash type if it is passed to fetchurl with an assert, instead fallback to other hash types if Nix is not new enough. This enables passing multiple hash types (e.g. sha256 and sha512) to fetchurl in a way that can be evaluated on both new and old Nixes that do/do not support the newer hash (sha512). See conversation at NixOS#15048.
I made #15441 for the PR I was talking about above. |
/cc #15048. I believe the usage of sha512 here at this point brings very little gain and can be quite painful to some users.
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)I tested rename, but none of the other binaries.