-
Notifications
You must be signed in to change notification settings - Fork 665
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
nix doesn't compile with bitflags-1.3.1 on rustc-1.45 #1491
Comments
Here's a related issue on the |
Thanks for reporting this. I'll try to fix it and publish a new release soon. |
Bitflags raised its MSRV in a minor version, forcing all consumers to follow suit. Fixes nix-rust#1491
Bitflags raised its MSRV in a minor version, forcing all consumers to follow suit. Fixes nix-rust#1491
Ok, I released v0.20.1, v0.21.1, and v0.22.1 to fix the issue. I'm not planning to make new releases for older branches, because we switched CI providers beginning with v0.20.0. To those of you still using Nix 0.19.1 or older, upgrade! Either upgrade Nix, or rustc. |
@asomers when will this restricted dependency version constraint be relaxed? I believe an acceptable workaround for folks not having a |
For now, you can use put |
Thank you! |
Any word on the 0.23 release? |
libc made a release a few days ago. There's just one more PR that needs to get finished before we can release 0.23: #1504 . |
Just released 0.23.0. |
This is a new feature in Cargo 1.56.0, currently in beta. Once Nix's MSRV is >= 1.56.0, this feature will prevent future problems like the bitflags 1.3.0 fiasco. Issue nix-rust#1491 Issue nix-rust#1510 Issue nix-rust#1548 Issue nix-rust#1555
@asomers This doesn't affect me personally, but you might want to know that the "< 1.3.0" bound on the bitflags dependency is forcing nix 0.20, 0.21, and 0.22 to resolve to the vulnerable versions 0.20.0, 0.21.0, and 0.22.0 when they appear in a dependency graph that also includes bitflags >= 1.3.0. This is a worrying behavior of Cargo's dependency resolver that I personally didn't know about until I ran |
Sigh, this stupid bitflags problem has caused me more trouble than anything else in the history of this crate. But I think I've got a better solution. PR #1560 will get rid of the bitflags dependency entirely, and #1561 will permanently fix the problem for users of Cargo 1.56.0 and up. I'm just waiting on somebody to test 1560, then I'll publish a new release that includes it. |
1561: Declare the MSRV in Cargo.toml r=rtzoeller a=asomers This is a new feature in Cargo 1.56.0, currently in beta. Once Nix's MSRV is >= 1.56.0, this feature will prevent future problems like the bitflags 1.3.0 fiasco. Issue #1491 Issue #1510 Issue #1548 Issue #1555 Co-authored-by: Alan Somers <asomers@gmail.com>
1561: Declare the MSRV in Cargo.toml r=rtzoeller a=asomers This is a new feature in Cargo 1.56.0, currently in beta. Once Nix's MSRV is >= 1.56.0, this feature will prevent future problems like the bitflags 1.3.0 fiasco. Issue #1491 Issue #1510 Issue #1548 Issue #1555 Co-authored-by: Alan Somers <asomers@gmail.com>
Because of this, I can no longer just I think it is a mistake for nix to regard MSRV bumps as breaking changes. It should be the exception that you have to fiddle with your dependency versions to get things to work securely. Currently, nix optimizes for compatibility with older Rust versions that aren't maintained (at least by upstream) while degrading the experience (and possibly exposing vulnerabilities) for people who are using the latest, upstream-supported compiler. |
bitflags
version 1.3.1 was recently released.nix
specifies a dependency onbitflags
with version constraint"1.1"
. Without a previously workingCargo.lock
filecargo
is now free to choosebitflags
version 1.3.1 to satisfynix
's dependency. However, with thatbitflags
version,nix
doesn't compile onrustc
version1.45
. Here is one of the many errors I get:Since
nix
claims to build onrustc-1.41
and upwards, I think this is a bug/misconfiguration.The text was updated successfully, but these errors were encountered: