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. The annual rustc upgrade for Firefox in *stable does also require an annual addition of a new LLVM version in *stable. 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. > Thanks, > Andres cu Adrian 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.
