Hi, rustc includes a script, debian/make_orig-stage0_tarball.sh, to create a stage0.orig.tar.xz that can be used to bootstrap rustc. I don't think that's used much, since new updates in Debian sid will use X-1 from sid to build. However, when uploading a (much newer) version to (old)stable, we don't have X-1, so we need to create and use a -stage0 tarball. The issue I find is that upstream doesn't support some of our release architectures, so when doing these backports, we lack a way to bootstrap the new version on those architectures. See for example [1]. One possibility would be to create the -stage0 tarballs using Debian sid packages for X-1. I haven't looked in detail, but perhaps we would need statically linked binaries, which could be done in an extra build and placed in a rust-static .deb. Then make_orig-stage0_tarball could look for those .debs from snapshot.debian.org. Thoughts? Cheers, Emilio [1] https://buildd.debian.org/status/fetch.php?pkg=rustc-web&arch=mipsel&ver=1.85.0%2Bdfsg3-1%7Edeb12u3&stamp=1754252552&raw=0
It is mainly used for rebootstrapping when ports/archs get out of sync. But I guess that might also have fallen out of favor with cross builds mostly working nowadays. Yes. I think for builds using those stage0 tarballs targeting stable we have three options: - build a static variant on every unstable upload - provide a script that cross-builds the missing stage0 targets (either using upstream build, or using an arch that has an upstream stage0 as starting point by doing a cross package build?) - use backports packages as stage0 input I think I'd favor the latter, since I already do the work for those ;) In recent history I think libgit2 was the only library pulled in that I had to backport as well (that was for Bookworm and for unofficial backports). It maybe would have been possible to avoid that by patching more aggressively. Of course, that would *only* help for Trixie, not Bookworm or older. If you need to support those, only the static or cross build variants would work at at the moment. Fabian
Right, I was going to say that. We are backporting rustc to older releases as well since we need it for firefox or clamav security updates. Those static builds sound better, as then getting the stage0 tarball is probably just a matter of running a script that downloads and packs some stuff. OTOH, that wouldn't work for e.g. mips* or armel, which are no longer present in sid (not even in ports). The same situation could happen in the future, where we have an architecture in (old)stable which no longer exists in sid, and so for which we don't have the required build. Which brings us back to the cross-build option. Cheers, Emilio
so I guess the most "robust" solution would be to do a combined approach: - the existing stage0 download where available - a script to drive cross-builds using whichever stage0 (upstream or packaging based or both?) - a script converting (backports/cross-built) packages to stage0 tarballs - allowing the stage0-tarball to contain either version N or N-1 the existing stage0 covers targets where upstream has tier2+host tools support the cross build script would allow filling gaps where upstream lacks support the package-to-stage0 conversion allows not relying on upstream at all allowing both N and N-1 just like for the regular build increases the chances of having *some* stage0 available technically it's possible to reduce the bootstrap chain with extra patches, but I am not sure we want to go down that route..