Fix build metadata handling in SemVer versions about crates.io

[Turbo87]

#6518 has now been deployed. in other words: crates.io no longer allows "publishes with versions only differing in metadata"

[epage]

Ah, that pointed me to this being a dupe of #1059

[Turbo87]

for cross-referencing: we discussed the situation on Zulip (see https://rust-lang.zulipchat.com/#narrow/stream/318791-t-crates-io/topic/const_fn_assert/near/356688583)

we decided to remove const_fn_assert#0.1.2+deprecated from crates.io since our backend shouldn't have accepted the publish in the first place. I've also sent an email to the crate owner explaining the situation.

since we already have #1059 for tracking the problem I'll go ahead and close this issue here since the const_fn_assert situation itself has been resolved AFAICT.

[Turbo87]

crates.io/src/controllers/krate/publish.rs

Line 190 in 127ac54

let hex_cksum: String = Sha256::digest(&tarball_bytes).encode_hex();

suggests that we calculate the checksum ourself, so I'm quite curious now what went wrong with that publish 🤔

[Turbo87]

I think the problem here is how "build metadata" in the version field is handled. You can see at https://crates.io/crates/const_fn_assert/versions that crates.io now has 0.1.2 and 0.1.2+deprecated. crates.io currently treats them as different versions (for no good reason IMHO), and I assume cargo ignores the build metadata and downloads a different crate file that does not correspond to the build metadata.

/cc @rust-lang/cargo

[sdroege]

Ah that would make sense and would at least be an honest mistake. Thanks for checking this so fast :)

[epage]

rust-lang/cargo#11412 for where the cargo team has discussed this