Some portions of the rust toolchain are written in rust itself, so a bootloading stage (stage0) is employed. Relevant examples are the rust compiler itself (rustc ) and the runtime (libstd, rt & co.).
The procedure is:
- determine host arch (arch+kernel+libc)
- download proper compressed stage0 (or use a locally-provided one)
- uncompress stage0 and use it to build stage1, stage2, target.
This poses some issues:
- downloading stuff from the net is not ok
- bundling all the artifact is equally bad
- using external artifact doesn't help reproducible builds
- building on arch supported only by Debian is impossible
We are in a situation a bit different from other compilers that need to be bootstrapped. In particular, many of them are not self-hosted (ie. they can use a C/other-lang stage0) or have a stable language that can be bootstrapped from previously installed compilers or build-essential tools.
Rust also doesn't currently support cross-bootstrapping among different arches, due to some confusion between target and host.
Rust is currently an experimental project. We aim at having it in sid/experimental but (probably) not in jessie, and restricted to main arches (i386/amd64). Once language stability is reached, some of the bootstrapping issues may get alleviated and better arch coverage achieved.
We currently envisions three possible scenarios. We know that some of them are against policy, infeasible or just plainly wrong. However, we are brainstorming here in order to reach a consensus with ftp-masters.
- use upstream binaries, download them from the web: this would let us build everywhere and keep in synch with upstream, source package would be easy and no self-dependency involved. Build-reproducibility would benefit from this. However, mostly everything of this is against policy.
- use a pre-built binaries, bundle them in src: bundle either upstream stage0 or a self-built signed one. This would mean that the source package will grow linearly the more arches get supported. It doesn't involve networks downloads but it's still using third-party artifacts.
- bootstrap once locally, then upload a pre-bootstrapped package: we use system installation to bootstrap, but this would introduce a self-dependency loop. As the language is not yet stable, whis would mean local re-bootstrapping on each upstream release until 1.0. This seems to satisfy policy, however distro bootstrappers may be unhappy.