Skip to content
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

Merged
merged 1 commit into from
May 7, 2016

Conversation

aneeshusa
Copy link
Contributor

  • Tested using sandboxing
    (nix.useSandbox on NixOS,
    or option build-use-sandbox in nix.conf
    on non-NixOS)
  • Built on platform(s)
    • NixOS
    • OS X
    • Linux
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

I tested rename, but none of the other binaries.

@mention-bot
Copy link

By analyzing the blame information on this pull request, we identified @edolstra, @nckx and @wkennington to be potential reviewers

@vcunat vcunat added the 1.severity: mass-rebuild This PR causes a large number of packages to rebuild label Apr 28, 2016
vcunat added a commit to vcunat/nixpkgs that referenced this pull request May 7, 2016
@vcunat vcunat merged commit 279a01d into NixOS:staging May 7, 2016
@vcunat
Copy link
Member

vcunat commented May 13, 2016

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.

@domenkozar
Copy link
Member

It's fine to upgrade NIx in master, let's bump lib/minver.nix

@vcunat
Copy link
Member

vcunat commented May 13, 2016

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.

@bjornfor
Copy link
Contributor

+1 for a bit of backwards compatibility here (allowing old nix to evaluate newer nixpkgs).

@aneeshusa
Copy link
Contributor Author

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.

@wkennington
Copy link
Contributor

Why would this be a problem, util linux is not a dependency of nix or
stdenv.

On Fri, May 13, 2016, 7:57 AM Aneesh Agrawal notifications@github.com
wrote:

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.


You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#15048 (comment)

@vcunat
Copy link
Member

vcunat commented May 13, 2016

No, util-linux isn't in (build-time) closure of nix. The problem would arise if we now bumped lib/minver.nix, causing refusal of evaluating anything by older nix versions.

Is it possible to specify both sha256 and sha512 hashes?

That won't help much. Changing hash type has to cause a rebuild, at least unless we make principal changes in nix itself.

@aneeshusa
Copy link
Contributor Author

@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:

  • Old Nix: fetchurl will see that Nix is older than 1.11 and not use sha512, will fall back to sha256, no rebuild.
  • New Nix: fetchurl will see that Nix is new enough to have sha512 and use it, will rebuild.

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.

@vcunat
Copy link
Member

vcunat commented May 13, 2016

We could change it, but backwards compatibility seems of less use when you can't share any depending binaries.

aneeshusa added a commit to aneeshusa/nixpkgs that referenced this pull request May 13, 2016
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.
@aneeshusa
Copy link
Contributor Author

I made #15441 for the PR I was talking about above.

vcunat added a commit that referenced this pull request May 14, 2016
/cc #15048. I believe the usage of sha512 here at this point
brings very little gain and can be quite painful to some users.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.severity: mass-rebuild This PR causes a large number of packages to rebuild
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants