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.
signature.asc
Description: PGP signature
