Re: chromium and rustc in bookworm

[Andres Salomon]

Okay, so I've gotten rustc 1.70.0+dfsg-6 (the prior version needed some bootstrap fixes) built on bookworm, and managed to use it to build chromium as well. Unfortunately -6 isn't building on mips64el, but I strongly suspect that this is something that won't happen in bookworm.

On 1/22/24 21:22, Timothy Pearson wrote:

I'm going to name the package rustc-web, and I'll send a patch for review hopefully tomorrow. Chromium 122's planned for release on Feb 20th, and I haven't yet checked if they've removed more C++ code in favor of Rust.

----- Original Message -----

From: "Andres Salomon" <dilin...@queued.net>
To: "Adrian Bunk" <b...@debian.org>, debian-release@lists.debian.org, 
pkg-rust-maintain...@alioth-lists.debian.net,
debian@fabian.gruenbichler.email, infini...@debian.org, sylves...@debian.org
Cc: "Timothy Pearson" <tpear...@raptorengineering.com>
Sent: Monday, January 22, 2024 8:17:15 PM
Subject: Re: chromium and rustc in bookworm

On 1/22/24 15:34, Mike Hommey wrote:

On Mon, Jan 22, 2024 at 03:39:08AM +0200, Adrian Bunk wrote:

On Sun, Jan 21, 2024 at 06:55:31PM -0500, Andres Salomon wrote:

...

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.

IMHO c) would be best, with one rustc-* package shared for both browsers.

AFAIK rustc 1.78 (to be released in May) will be required by the next
Firefox ESR 128, and bookworm will switch to 128 in September/October.

At this point, there is no saying which specific version will be
required, but the one thing that is sure is that it will be at least
1.70. If I had to guess, I'd say it might be 1.75, but so far, it looks
like it might as well stay 1.70.

Interestingly, 1.70 is what we currently have in unstable, which means
unstable is > 6 months outdated already.

Mike

Sounds like (c) is the winner. Now for the bikeshedding -
rustc-browsers? rustc-backport?  rustc-unstable?

Agreed on the course of action.  For the bikeshed, rustc-web?  I'm thinking of 
embedded browsers (things like electron) that may end up depending on it, and 
web might be more descriptive for all of that?

As far as release cadence, at least from my end if firefox-esr needs a
newer rustc backport then chromium will be able to quickly adjust. We
have almost weekly security updates, which can be adapted to work with a
newer rustc. In the other direction, I'm expecting/hoping that we can
just manually enable experimental features in chromium crates until a
newer rustc is absolutely necessary. As with clang, I expect that would
be roughly every 12-18 months.

I'm a bit less optimistic, but we can see what the cadence settles in as.  
Personally I'd be surprised if we can get away with anything slower than a 6 
month cadence, just based on how rapidly Google is iterating, but we just won't 
know until we have a number of Rust-dependent releases under our belt.

OpenPGP_0x645D0247C36E7637.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature