Hi! rustc currently builds the Rust standard libraries (libcore, liballoc, libstd) for each of the supported Debian architectures, and additionally also for some wasm targets, shipped as `libstd-rust-dev-wasm32:all`. This package is :all because it doesn't match any of the existing Debian architectures, and rustc of any arch can use the resulting files to compile for the corresponding targets (currently `wasm32-unknown-unknown` aka browsers, and `wasm32-p1`/`wasm32-p2` which use `wasi-libc`, which is similarly "fake" :all).
We also used to ship windows standard libs built via the mingw toolchain, but those were dropped in Trixie (and those were not :all anyway, but mapped to amd64/i386). I would like to introduce new packages for (Tier 3) BPF targets `bpfeb-unknown-none` and `bpfel-unknown-none`, to support use cases like aya-rs properly. These exist in a similar void like the wasm ones - they don't really match any of the Debian architectures, and rustc can build and use them on any build architecture. Obviously with the caveat that endianness matters here, so you need to select the right variant of the target matching the platform you want to run the compiled BPF bytecode on. Currently users that want to use those targets with the packaged toolchain need hacks to enable building libcore from scratch for that target, which in turn means a lot of guides push people to use rustup and nightly toolchains, even though the packaged one would work fine if it would ship a pre-compiled libcore. Is there a better way to handle this or is introducing a new :all package fine? Similar questions will arise in the future once 64-bit wasm stabilizes.. Would be happy to get input, Fabian
