Comment 8 for bug 2020000

So, there was a slight communication mishap on the review. It was *not* completed, just ongoing.

I finished the first round, with the following comments:

* Could you add a Recommends: rustc-doc to cargo doc? I'm betting there are more cross references in that direction than the other one (that already has that field).

* What's your rationale behind using binary version wrangling for cargo vs just being vigilant that it might be a cause of breakage in the future? I'm not saying you're wrong, but I tend to concur with Michael's comment on the spec that "we would want to have a good reason to do that" :slightly_smiling_face:

I know it might seem weird coming from me since I raised the issue in the first place, but I mainly wanted an acknowledgement that you were aware of the potential problems this might cause us in the future. The issues I find with sticking with the crate version number are the following:

  - This version number is unexpected for pretty much any Rustacean. Nobody uses it.
  - That's a minor papercut, but that means you can't just do a $RUSTC_PACKAGE_VERSION.deb to quickly designate all debs from that package. Like I said, minor, but highly annoying. And yes I know it's unsafe in the general case, but it's worked pretty well for me so far :wink:
  - You have to remember to bump the version number when doing a packaging upload (as in not changing the upstream sources)
  - This adds some more complexity to d/rules

* (kind of out of scope as it's not in src:cargo either) at some point *someone* wrote some autopkgtests for cargo that were basically just dealing with a simple crate (creating the project, adding a dependency, etc...). I don't know who did it nor where the code ended up, but it'd be a nice thing to have in addition to the full-blown rebuild. Again, out of scope.