[Pkg-rust-maintainers] chromium and rustc in bookworm

[Timothy Pearson]

----- Original Message -----
> From: "Andres Salomon" <dilinger at queued.net>
> To: "Adrian Bunk" <bunk at debian.org>, debian-release at lists.debian.org, pkg-rust-maintainers at alioth-lists.debian.net,
> debian at fabian.gruenbichler.email, infinity0 at debian.org, sylvestre at debian.org
> Cc: "Timothy Pearson" <tpearson at 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.