[Pkg-rust-maintainers] 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.

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.


On 1/22/24 21:22, Timothy Pearson wrote:
> 
> 
> ----- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x645D0247C36E7637.asc
Type: application/pgp-keys
Size: 3898 bytes
Desc: OpenPGP public key
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20240213/3f261a47/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20240213/3f261a47/attachment.sig>