Hi,Soon, Chromium 121.x will be released with a hard requirement on a Rust compiler. Upstream ships a bundled rustc by default, which is undesirable for numerous reasons (least of which, it balloons the orig.tar.xz to 3GB!).
I've gotten chromium 120 to build with Debian's rustc packages in sid with some help (and rustc updates) from Fabian and others on IRC. I would like to get Chromium building with Rust in bookworm, but at the very least the profiler patch for the rustc package described in #1043311 is necessary. We thankfully don't have to worry about bullseye, see #1061268.
I see several potential options:a) Continue disabling Rust support in Chromium, including reverting any patches that make it required. Upstream has said that they will start removing C++ code in favor of Rust code, so I don't see this as a long-term solution. But, delaying any updates to rustc in bookworm might change the decision-making process for the following options.
b) Backport the profiler patch to bookworm's rustc, and do a s-p-u update to Bookworm's rustc. Since this adds a new feature, I don't view it as too risky, but the release team or rust team may feel differently. The main downsides to this are the potential for breaking existing packages in stable, and the fact that Chromium will undoubtedly begin to rely on newer Rust language features (as they do with Clang) which may not work on bookworm's 1.63.0. Once that happens, we'll be right back here.
c) Much like the Firefox maintainer(s) created rustc-mozilla for (old)oldstable, we create a 'rustc-chromium' package for bookworm. It could even be used for Firefox if their ESR updates start needing newer Rust language features (in which case, maybe 'rustc-newer' or 'rustc-browsers' is a better name for it? Or like Clang, include the major version and call it 'rustc-1.70').
As I'm still messing around with bookworm's rustc(+profiler) as well as trying to get Chromium 121.x to build in Sid, I don't have a strong opinion on this yet. However, I wanted to bring it to everyone's attention, and see if anyone else did have strong opinions either way. If one of the teams feels strongly against option (b) for example, I won't bother continuing to work on that option.
Thanks, Andres
Attachment:
OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature