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

[Fabian Grünbichler]

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:
> >...
> > 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.
> 
> 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.

with my (nowdays main) rustc maintainer hat on, I agree that this would
be the best approach. I do plan on also doing regular "normal" backport
uploads of rustc/cargo/wasi-libc to bpo once I am done with the DD
process, so those should hopefully already iron out most
backporting-related kinks and might serve as a nice forking-off point
for browser-toolchain packages going into regular stable (once they are
available, that is).

> The annual rustc upgrade for Firefox in *stable does also require an 
> annual addition of a new LLVM version in *stable.

not necessarily, but likely, especially if one doesn't want to run a
combination that's untested both in Debian's variant of the Rust
toolchain and upstream. upstream has a minimum and default LLVM version
(the latter is bundled upstream and sometimes even carries specific
cherry-picks), and the packaged one usually reflects upstream's default.

> Short-term a version of the bookworm rustc with the profiler patch you 
> need could then be uploaded as a first version of this rustc-browsers
> (or however it is named) package.
> 
> The critical question is whether the annual LLVM+rustc upgrade cadence 
> for Firefox in stable is compatible with what Chromium needs.

this one I cannot answer, but hopefully Mozilla/Chromium maintainers or
upstreams can.

> BTW:
> I am not personally involved in any of the mentioned packages, just 
> pointing out what seems to be the least work while avoiding even more
> rustc and LLVM versions in stable releases.

for my part, I am happy to help with reviewing patches, assisting with
backporting snags, adapting the regular packages to make those efforts
easier, etc.pp.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20240122/63f36394/attachment.sig>