[Pkg-rust-maintainers] Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

[Adrian Bunk]

On Mon, Nov 29, 2021 at 05:32:30PM +0100, Julien Cristau wrote:
> cc: rustc and firefox maintainers
> 
> On Tue, Nov 23, 2021 at 03:20:45PM -0500, Roberto C. Sanchez wrote:
> > In preparing the rustc 1.51 upload/backport (to support backports of the
> > latest firefox-esr and thunderbird packages) it has been suggested that
> > to avoid some issues associated with providing a significant new version
> > of rustc in the rustc binary package (along with the associated library
> > packages), that I prepare the 1.51 rustc package with a different name.
> > Following the model of what was done for gcc, nasm, and nodejs, I was
> > considering source package rustc-mozilla with a single binary package
> > (also rustc-mozilla) to ensure that rdeps don't end up getting surprised
> > by a new rustc.  Would this be considered acceptable for the bullseye
> > and buster uploads of rustc 1.51?
> 
> 2 things:
> - I think we should pick 1.53 if possible, since that's what mozilla use
>   for their esr91 binaries

I was suggesting 1.51 since the smaller the difference to the currently 
used version, the lower the risk of new bad surprises when updating 
rustc.

Roberto is doing this primarily for LTS, and for stretch LTS next years
Firefox that will require yet another rustc update will no longer be an
issue.

The Debian packages of rustc 1.53 in experimental and unstable were 
built with LLVM 12, we won't see before it enters stable-pu whether
building rustc 1.53 with LLVM 11 breaks on some architecture (unlikely
but not impossible, especially with the error thresholds).

> - I don't think we need to rename the packages unless there's evidence
>   of breakage that can't be easily fixed by either simple patches or
>   removing the affected packages.  Renamed packages are acceptable but
>   that seems like extra work and overhead that may not be necessary.

We have already learned the hard way that such evidence might appears
after it is too late.

In bullseye there are > 800 non-Firefox packages build depending on rustc.

In buster there are "only" around 450 packages build depending on rustc.
One of them is librsvg, which failed to build with last years new rustc 
for Firefox.

The librsvg updated for rustc 1.41 updated for last years Firefox ESR
did build on amd64 but not on ppc64el.

And BTW, this rustc/firefox misery also blocks the CVE-2019-20446 fix in 
librsvg from entering buster.

Assuming ppc64el will continue to not be part of LTS also for buster,
the easiest solution will be to re-upload the fixed librsvg to 
buster-security immediately after LTS starts for buster.

For rustc 1.41 in buster this is exactly the evidence you are asking for.
And it could not have reasonably be discovered before uploading rustc.

The lesson learned is that the normal rustc package can no longer be 
updated in stable series now that Firefox is no longer the sole user.

> Cheers,
> Julien

cu
Adrian