Checksum failing when using semver build meta-data

[jake-ruyi]

Maybe not a bug.

Problem
Crates with semver build metadata (e.g. 1.1.1+2) seem to have issues with:

error: checksum for `runng-sys v1.1.1+4` changed between lock files

Or:

error: failed to verify the checksum of `runng-sys v1.1.1`

Details:

• I wanted a crate of FFI bindings to track the version of the native library (e.g. 1.1.1)
• Tried to use semver build metadata for "minor" crate updates that still used the same version of the native library (e.g. 1.1.1+2)
• First ran into problems getting doc.rs to pull and build the correct version (failed builds), eventually getting it to work by yanking all but the most recent crate (crates.io version history)
• If all versions except 1.1.1+4 are yanked, Cargo.toml with runng-sys = "1.1.1" fails with error: checksum for XYZ changed between lock files
• If all versions except 1.1.1 and 1.1.1+4 are yanked, Cargo.toml with runng-sys = "1.1.1" fails with error: failed to verify the checksum
• Everything is fine when using path dependencies: runng-sys = { path = XYZ }

I've flailed around with this enough that I'm not entirely sure what the problem is. Rather than publishing more packages and digging myself a deeper hole, thought I should stop and ask.

Also see:

• Originally reported here
• Additional info here

Steps
Made a dummy package cargo_issue_6504 to verify it has nothing to do with my stuff.

Both 1.1.1 and 1.1.1+1 are not yanked:

1. cargo new test2
2. In Cargo.toml, cargo_issue_6504 = "1.1.1"
3. cargo build fails with failed to verify the checksum

2.2.2 is yanked, 2.2.2+1 is not:

1. cargo new test2
2. In Cargo.toml, cargo_issue_6504 = "2.2.2"
3. cargo build succeeds
4. Second cargo build fails with checksum for XXX changed between lock files

Possible Solution(s)

• Seems to be several dangling issues related to semver + metadata (1, 2, several others)
• Supporting build metadata adds flexibility (especially with publishing to crates.io being permanent), but...
• Maybe there should at least be a warning that "your package isn't going to work"

Notes

Output of cargo version:

cargo 1.31.0 (339d9f9c8 2018-11-16)

[alexcrichton]

Thanks for the report!

I've tracked this down to the fact that {Hash,Eq} for semver::Version doesn't actually include build metadata so Cargo's own internal map of versions to hashes gets mixed up because the Version instances collide with one another.

I think that according to the semver spec 1.1.1 is actually equivalent to 1.1.1+a, so I actually think it's a violation that we allowed multiple of those versions to be published in the first place!

@steveklabnik just wanted to double check with you, but does that sound right on the semver side of things?

[ehuss]

Rejecting on publish seems to be the inclination in rust-lang/crates.io#1059.

Also, maybe Cargo should warn if you have metadata in a versionreq. For example, bitflags = "=1.0+foo" works.

[alexcrichton]

Ah right yes, forgot about that! And yeah I think it's probably worthwhile for Cargo to warn and/or reject build metadata on version requirements

[steveklabnik]

Yes, Semver completely ignores build metadata for purposes of comparison. (Both the spec and the library)

…

On Jan 3, 2019, at 2:40 PM, Alex Crichton ***@***.***> wrote: Ah right yes, forgot about that! And yeah I think it's probably worthwhile for Cargo to warn and/or reject build metadata on version requirements — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[alexcrichton]

Ok! Let's close this in favor of rust-lang/crates.io#1059 then