Merge Cargo source package into Rust

Preliminary packages were uploaded to https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.68-unify/+packages.
You can find the source changes at https://git.launchpad.net/~canonical-foundations/ubuntu/+source/rustc/log/?h=exp/unified-source.

I took a very quick skim and it looks OK. Did you compare the list of files installed by the old and new rustc and cargo packages?

> I took a very quick skim, and it looks OK. Did you compare the list of files installed by the old and new rustc and cargo packages?

The files installed into rustc stayed the same. The files for cargo are expected to be slightly different due to building together with rustc. The `cargo-doc` package will now contain more comprehensive API documentation and user manuals (previously missing).

The full-world rebuild test results are in!
You can find all the packages here: https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.68-wrb/+packages

Most failures were due to missing dependencies (dependency wait) from Debian (missing sync?).
Some failures were due to GCC internal errors (https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.68-wrb/+build/26224085).
Some others were due to our toolchain being too new.

Overall, no issues related to the merge were detected in the rebuild.

Update: This is still in progress, pending review from Simon.

Yes, I'm sorry, I've been swamped in the past weeks. I'm setting aside
some time next Tuesday morning (European) to do a first review,
hopefully get the ball rolling again.

Update: The review has been completed. Upload will follow very soon.

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.

Hi Simon,

I have added `Recommends: rust-doc` to the cargo-doc package.

After investigating and carefully considering the binary version situation, I decided to let the cargo binary package honour the rustc package version.
The reasonings are as follows:

- The Cargo crate version is only meant to be used when using Cargo as a library instead of a tool.
- Currently, Cargo and Rustc are released in sync; there will not be a situation where a new Rust release does not contain a new release of Cargo.
- Cargo, when building with Rustc, reports the Rustc version.

For the autopkgtest, I will remember to work on that after this merge.

Revised packages were uploaded to https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.68-unify/+packages.
You can find the source changes at https://git.launchpad.net/~canonical-foundations/ubuntu/+source/rustc/log/?h=exp/unified-source.

This bug was fixed in the package rustc - 1.68.0+dfsg0ubuntu1-0ubuntu1

---------------
rustc (1.68.0+dfsg0ubuntu1-0ubuntu1) mantic; urgency=medium

  * New upstream release 1.68.0 (LP: #2009920)
    - d/copyright: Update copyright information for new dependencies
      and also remove copyright data for deleted dependencies
    - d/patches: Refresh patches
    - d/control: Update vendored deps field
    - d/control: Refresh vendored dependencies list
  * d/p/ubuntu-rustdoc-replace-cargo-links.patch: Replace Cargo related
    links with external web links instead of the local links to avoid
    link-checker errors (because we package Cargo separately)
  * Merge Cargo source package into Rust (LP: #2020000)
    - d/*: copies Cargo Debian manifests into Rust
    - cargo: add Cargo sources to the source tree
    - d/patches: adapt Cargo-specific patches to the new source tree
      structure
    - d/patches, vendor: remove vendored C sources and prebuilt blobs
    - vendor: vendor Cargo-specific dependencies
    - d/control: update vendored dependency list
    - d/rules: revise openssl source check
    - d/cargo.*: install Cargo-specific files
    - d/config: enable Cargo module in the rustbuild configuration
    - d/patches: remove non-Linux platform modules
    - d/rules: use system libssh2 for Cargo
    - d/patches: restore the usage of rustc-workspace-hack to
      reduce the build time and avoid crates feature resolution failure
    - d/patches: remove patches that patch out Cargo from the docs
    - d/rules, d/cargo.*: build and install Cargo API docs
    - d/control, d/rules: install Cargo bash completions
    - d/copyright: update copyright information
    - d/control: make cargo-doc recommends rust-doc

 -- Zixing Liu <email address hidden> Wed, 17 May 2023 14:15:17 -0700