{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidp3zftd34yptzbx5s3zczqc2wwl26d3vt4ed6pvedfjg6op35ra4",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mjjn6wbq4rj2"
  },
  "path": "/t/yanking-a-crate-better-than-deleting-it/24175#post_2",
  "publishedAt": "2026-04-15T09:11:54.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "I agree, reusing a crate name is risky.\n\nBut here is an idea: when a crate is deleted and after some time (years preferably, not months), someone re-register it, what if existing `Cargo.lock` would be reported as incompatible? Using a generation counter to prevent the ABA problem.\n\nLike, every time a crate name is reused, it gets an unique name `_unique_cratename_N` where N is an increasing counter (crate names with this pattern get prevented to be registered). In `Cargo.lock`, whenever a crate was mentioned was `cratename` (like all lockfiles today do), it gets interpreted as `_unique_cratename_0`, which prevents building if the crate were re-registered (since the new crate will be called `_unique_cratename_1`). But whenever new code depends on `cratename`, Cargo will generate a `Cargo.lock` that refers to the right generation counter.\n\nThis should probably not be required if the crate being is very new, has no downloads, has no dependencies in crates.io, etc.\n\nThere's a problem with this though. This scheme only works with new Cargo - older versions of cargo would be permanently prevented from depending on deleted crates that were later re-registered. (maybe there's a variant of this idea that could accommodate older versions of cargo too)",
  "title": "Yanking a crate better than deleting it"
}