[FFe] Remove Windows libraries from Rust source package

[Zixing Liu]

We want to remove Windows libraries (mostly windows-sys and friends) from the Rust source package.

They contain binary blobs and auto-generated code that consume much storage space (~700 MiB).
Removing them also makes the source package easier to audit.

[Zixing Liu (liushuyu-011)]

Preliminary packages were uploaded to https://launchpad.net/~liushuyu-011/+archive/ubuntu/rust-updates-1.71/+packages.
And also, its corresponding source at https://git.launchpad.net/~canonical-foundations/ubuntu/+source/rustc/tree/?h=merge-1.71.
You can find the autopkgtest results on this page: https://autopkgtest.ubuntu.com/results/autopkgtest-mantic-liushuyu-011-rust-updates-1.71/?format=plain (tests that represent library removal have a timestamp dated after 20230912).

---

Lintian report:

E: rustc source: field-too-long Vendored-Sources-Rust (10433 chars > 5000)
W: rustc source: mismatched-override missing-license-paragraph-in-dep5-copyright debian/copyright mpl-2.0+ [debian/source/lintian-overrides:15]
W: rustc source: missing-license-paragraph-in-dep5-copyright mpl-2.0+ [debian/copyright:2044]
W: rustc source: unknown-field Vendored-Sources-Rust
N: 0 hints overridden; 1 unused override
N: Some overrides were ignored.
N: Use --verbose for more information.
Finished running lintian.

[Steve Langasek (vorlon)]

Reverse-Depends
===============
* dh-cargo (for cargo)

Packages without architectures listed are reverse-dependencies in: amd64, arm64, armhf, i386, ppc64el, s390x
Reverse-Testsuite-Triggers
==========================
* rustc (for cargo)
* rustc (for rustc)

Reverse-Build-Depends
=====================
* clamav (for rust-gdb)
* clamav (for rustfmt)
* clamav (for cargo)
* librsvg (for cargo)
* librsvg (for rustc)
* mdevctl (for cargo)
* mesa (for rustc)
* mozjs115 (for rustc)
* mozjs115 (for cargo)
* python-cryptography (for cargo)
* rustc (for cargo)
* rustc (for rustc)
* thunderbird (for rustc)
* thunderbird (for cargo)

cargo-doc (from rustc) is seeded in:
  kubuntu: supported
  lubuntu: supported
  ubuntu-budgie: supported
  ubuntukylin: supported
  xubuntu: supported
rust-doc (from rustc) is seeded in:
  kubuntu: supported
  lubuntu: supported
  ubuntu-budgie: supported
  ubuntukylin: supported
  xubuntu: supported

rustc is in main but none of its binary packages are on any images, so this does not impact preparation of images for the final release.

https://launchpad.net/ubuntu/+source/rustc/1.71.1+dfsg0ubuntu1-0ubuntu2/+build/26518606 shows an 11-hour build on riscv64, so it is possible to get this done and released in the mantic release pocket prior to closing it if uploaded today or tomorrow (Wednesday).

If this does not make it into the mantic release pocket, do you want this done as an SRU?

[Steve Langasek (vorlon)]

This, of course, is the biggest risk:

$ reverse-depends src:rustc -a source |wc -l
5463
$

We do not have time for rebuild testing all of its reverse-dependencies to confirm that this change does not regress anything. We would have time to do that via an SRU.

They are Windows libraries, so it seems obvious that they shouldn't be needed for any builds of Ubuntu packages that build-depend on rustc. But can you describe explicitly how and when these Windows libraries are used, so we can decide how confident we are that this change will not impact behavior of the rustc package in Ubuntu?

[Zixing Liu (liushuyu-011)]

> But can you describe explicitly how and when these Windows libraries are used, so we can decide how confident we are that this change will not impact behavior of the rustc package in Ubuntu?

Yes. Those Windows libraries included in the Rust source tarball are not for end-user consumption (meaning they are not meant to be used by Rust developers using the compiler).

They are used by Cargo on Windows during the runtime to create job-servers (since GNU Make-like job-servers are impossible to implement on Windows). Rust compiler relies on those libraries to print colourful output on Windows (via comhost.exe).

Removing them doesn't affect the ability of the Rust toolchain to generate Windows binaries via either the MinGW toolchain or the Wine-hosted MSVC environment.

In fact, those are actually not compiled into the binary due to platform-gating. They exist in the Rust source tarball because the source tarball is for all the support platforms (Linux/Windows/macOS/*BSD).

[Steve Langasek (vorlon)]

Thanks, that suffices for me; FFe approved.

Please don't overlook this other question:

If this does not make it into the mantic release pocket, do you want this done as an SRU?

[Steve Langasek (vorlon)]

And please make sure this is uploaded no later than Wednesday UTC working hours if you want this accepted into the mantic release pocket.

[Zixing Liu (liushuyu-011)]

> If this does not make it into the mantic release pocket, do you want this done as an SRU?

We can do this as an SRU if the upload did not make it in time.

And yes, We can perform a full-archive rebuild test for it if there are any concerns regarding the behaviour change. Some of the bad Rust micro-packages might also surface as part of the rebuild.

[Launchpad Janitor (janitor)]

This bug was fixed in the package rustc - 1.71.1+dfsg0ubuntu2-0ubuntu1

---------------
rustc (1.71.1+dfsg0ubuntu2-0ubuntu1) mantic; urgency=medium

  * Remove Windows libraries and dependencies
    (windows and windows-sys) (LP: #2036123)
    - d/p/d-0020-remove-windows-dependencies.patch,
      d/p/d-0021-vendor-remove-windows-dependencies.patch: add patches to
      remove references to Windows-specific libraries
    - d/copyright: Exclude all the removed libraries
    - d/control: Refresh dependency list

 -- Zixing Liu <email address hidden> Wed, 06 Sep 2023 16:41:39 -0600