[Bug 2100266] Re: Versioned cargo wrapper script points to default cargo

Tue Apr 14 16:10:09 UTC 2026

** Merge proposal linked:
   https://code.launchpad.net/~maxgmr/ubuntu/+source/rustc-1.91/+git/rustc-1.91/+merge/503669

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to rustc-1.76 in Ubuntu.
Matching subscriptions: rustc-1.93
https://bugs.launchpad.net/bugs/2100266

Title:
  Versioned cargo wrapper script points to default cargo

Status in rustc-1.76 package in Ubuntu:
  Invalid
Status in rustc-1.77 package in Ubuntu:
  Invalid
Status in rustc-1.78 package in Ubuntu:
  Invalid
Status in rustc-1.79 package in Ubuntu:
  Invalid
Status in rustc-1.80 package in Ubuntu:
  Invalid
Status in rustc-1.81 package in Ubuntu:
  In Progress
Status in rustc-1.82 package in Ubuntu:
  In Progress
Status in rustc-1.83 package in Ubuntu:
  In Progress
Status in rustc-1.84 package in Ubuntu:
  In Progress
Status in rustc-1.85 package in Ubuntu:
  In Progress
Status in rustc-1.88 package in Ubuntu:
  In Progress
Status in rustc-1.91 package in Ubuntu:
  New
Status in rustc-1.92 package in Ubuntu:
  New
Status in rustc-1.93 package in Ubuntu:
  New
Status in rustc-1.76 source package in Focal:
  New
Status in rustc-1.77 source package in Focal:
  New
Status in rustc-1.78 source package in Focal:
  New
Status in rustc-1.79 source package in Focal:
  New
Status in rustc-1.80 source package in Focal:
  New
Status in rustc-1.76 source package in Jammy:
  New
Status in rustc-1.77 source package in Jammy:
  New
Status in rustc-1.78 source package in Jammy:
  New
Status in rustc-1.79 source package in Jammy:
  New
Status in rustc-1.80 source package in Jammy:
  New
Status in rustc-1.76 source package in Noble:
  New
Status in rustc-1.77 source package in Noble:
  New
Status in rustc-1.78 source package in Noble:
  New
Status in rustc-1.79 source package in Noble:
  New
Status in rustc-1.80 source package in Noble:
  New
Status in rustc-1.81 source package in Noble:
  New
Status in rustc-1.82 source package in Noble:
  New
Status in rustc-1.83 source package in Noble:
  New
Status in rustc-1.84 source package in Noble:
  New
Status in rustc-1.85 source package in Noble:
  In Progress
Status in rustc-1.80 source package in Oracular:
  Won't Fix
Status in rustc-1.81 source package in Oracular:
  Won't Fix
Status in rustc-1.81 source package in Plucky:
  Won't Fix
Status in rustc-1.82 source package in Plucky:
  Won't Fix
Status in rustc-1.83 source package in Plucky:
  Won't Fix
Status in rustc-1.84 source package in Plucky:
  Won't Fix
Status in rustc-1.85 source package in Questing:
  In Progress
Status in rustc-1.88 source package in Questing:
  New
Status in rustc-1.88 source package in Resolute:
  In Progress

Bug description:
  [ Impact ]

   * If you use the Cargo wrapper script provided by a versioned
     cargo package, e.g. /usr/lib/rust-1.85/share/cargo/bin/cargo,
     it will invoke /usr/bin/cargo rather than
     /usr/lib/rust-1.85/bin/cargo.

   * This means that users expecting a particular Cargo version are
     actually invoking the rust-defaults Cargo version behind the
     scenes.

   * Additionally, if the rust-defaults Cargo version isn't
     installed, the versioned Cargo wrapper script doesn't work at
     all (because it's trying to invoke the nonexistent default).

   * As stated in the comments of this bug report, this is blocking
     the update of authd's Rust dependencies.

   * This upload fixes the bug by making the Cargo wrapper script
     invoke the versioned Cargo instead.

  [ Test Plan ]

   * To ensure the fix is comprehensive, all documented usages of the
     wrapper script must be performed without installing any
     rust-defaults packages. That way, if the system attempts to use
     any default cargo functionality, we will get a hard "missing file"
     error rather than a silent usage of default cargo.

   * Install the versioned cargo and a basic Rust library dependency:
     - # apt install -y cargo-1.91 librust-anyhow-dev dpkg-dev

   * Create a new Rust project:
     - $ cargo-1.91 new hello
     - $ cd hello

   * Add the library dependency to the project:
     - $ cargo-1.91 add anyhow at 1

   * Edit ./src/main.rs to use anyhow:
     - $ echo 'fn main() -> anyhow::Result<()> { Ok(()) }' >src/main.rs

   * Download the makefile which runs all the different wrapper script
     functions:
     - $ wget 'https://drive.google.com/uc?export=download&id=1qv1n2WwCN26O1YLHF60pRR71xzWH9Inm' -O Makefile

   * Run the Makefile, setting the expected Rust version:
     - $ RUST_VERSION='1.91' make test

   * The script should fail when it tries to invoke /usr/bin/cargo.

   * To test the fixed version, add the PPA and install the fixed
     cargo-1.91:
     - # add-apt-repository -y ppa:maxgmr/lp2100266-2
     - # apt update
     - # apt install -y cargo-1.91

   * Running the Makefile once more should succeed:
     - $ RUST_VERSION='1.91' make test

  [ Where problems could occur ]

   * This upload changes the toolchain version which is invoked by the
     versioned Cargo wrapper. As a result, applying this SRU means that
     packages will be built with a different Rust version. The regression
     risk depends on the difference between the default Rust version and
     the patched Rust version for the given series. For example, on
     Noble, patching rustc-1.91 will mean that when running cargo-1.91,
     Rust 1.91 is used instead of the default of 1.75 on Noble. This
     means that anything that is built by the versioned rustc/cargo has
     a risk of FTBFS if they need to be rebuilt for whatever reason.

   * Since Rust upstream is committed to backwards compatibility, risk
     of FTBFS from upstream changes is minimal.

   * No Rust packages which build using the default non-versioned
     Rust (the overwhelming majority) will be affected at all.

   * Most FTBFS risk stems from packaging changes from the default
     version to the backported version. For instance, newer cargo
     packages add a key to packages' Cargo.tomls during preconfiguration.
     If a package already includes that key in its Cargo.toml, that
     package will FTBFS. 

   * Luckily, in practice, regression risk is very low because very few
     packages opt-in to using the backported versioned toolchains over the
     default version. For instance, not a single package in the archive is
     currently built by rustc-1.91 on Noble:
     - $ ./checkrdepends --include-provides --no-ports --suite noble \
           --archive-base 'http://archive.ubuntu.com/ubuntu' rustc
         [empty output]

   * To further verify that FTBFSs will be rare, I rebuilt some packages in
     a PPA[1]. They all built without issue except for lace, which failed
     due to the aforementioned duplicate Cargo.toml key issue. (I have
     submitted a fix for the issue[2].)

  [1]: https://launchpad.net/~maxgmr/+archive/ubuntu/lp2100266-2/+packages
  [2]: https://github.com/canonical/lace/pull/41

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rustc-1.76/+bug/2100266/+subscriptions