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

Max Gilmour 2100266 at bugs.launchpad.net
Mon Apr 13 22:37:43 UTC 2026 

** Description changed:

  [ 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.
+  * 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.
+  * 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).
+  * 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.
+  * 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.
- 
-  * In addition, it adds a new "versioned-cargo-wrapper" autopkgtest
-    which verifies that the Cargo version invoked by the wrapper
-    script matches the version of the package itself.
+  * This upload fixes the bug by making the Cargo wrapper script
+    invoke the versioned Cargo instead.
  
  [ Test Plan ]
  
-  * To reproduce on Noble, do the following:
-    - # apt install -y cargo-1.85
-    - $ /usr/lib/rust-1.85/share/cargo/bin/cargo --version
-      - This should produce a FileNotFoundError.
-    - # apt install -y cargo
-    - $ /usr/lib/rust-1.85/share/cargo/bin/cargo --version
-      - This should (incorrectly) show cargo 1.75.0.
+  * 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.
  
-  * To test the fix on Noble, do the following:
-    - # add-apt-repository -y ppa:maxgmr/rustc-lp2100266
-    - # apt update && apt upgrade -y
-    - # apt remove -y cargo
-    - $ /usr/lib/rust-1.85/share/cargo/bin/cargo --version
-      - This should now show cargo 1.85.1 (instead of FileNotFound)
-    - # apt install -y cargo
-    - $ /usr/lib/rust-1.85/share/cargo/bin/cargo --version
-      - This should also show cargo 1.85.1 (instead of 1.75.0)
+  * Install the versioned cargo and a basic Rust library dependency:
+    - # apt install -y cargo-1.91 librust-anyhow-dev dpkg-dev
  
-  * Additionally, the new "versioned-cargo-wrapper" autopkgtest
-    should pass.
+  * 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.
+  * 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.
  
-  * This means that, for example, on Noble, packages built with
-    cargo-1.85 were being built with 1.75 the whole time. When the
-    SRU is applied, all these packages will be (correctly) built with
-    1.85 as intended, but this could potentially cause builds to fail.
+  * Since Rust upstream is committed to backwards compatibility, risk
+    of FTBFS from upstream changes is minimal.
  
-  * This change does not affect the vast majority of Rust packages, as
-    they are all built with the default Rust version.
+  * No Rust packages which build using the default non-versioned
+    Rust (the overwhelming majority) will be affected at all.
  
- [ Other Info ]
+  * 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. 
  
-  * In d/rules, my exclusion of 'librustc_driver' from the dh_dwz step
-    is not related to this bug, but the build failed otherwise, so I
-    needed to include this fix as well.
+  * 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

** Merge proposal unlinked:
   https://code.launchpad.net/~maxgmr/ubuntu/+source/rustc-1.85/+git/rustc-1.85/+merge/498527

-- 
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

More information about the foundations-bugs mailing list