Now that libstd-rust-dev-bpf has landed, I would like to follow up on this thread and add the UEFI target standard libraries (x86_64-unknown-uefi and aarch64-unknown-uefi) to src:rustc, as a sibling of the existing -wasm32 and -bpf packages.
My motivation is the same one that drove the bpf addition. There is currently no way to build a Rust UEFI binary from packaged Debian alone, because the uefi target std is not shipped, so building for it requires rustup or -Zbuild-std on nightly. That keeps every Rust UEFI and firmware project out of the archive. I have a concrete consumer in mind: I maintain LamBoot, a memory-safe Rust UEFI bootloader, and it already builds on stable rustc for both x86_64-unknown-uefi and aarch64-unknown-uefi. The only piece missing for an in-archive build is the target std. Because these are Tier-2 targets, the upstream bootstrap already produces core and alloc for them, so neither nightly nor build-std is needed inside the archive. Fedora ships exactly this as rust-std-static-x86_64-unknown-uefi and rust-std-static-aarch64-unknown-uefi from its rust spec, which gives a working precedent to point to. The change would mirror the -bpf stanzas almost line for line. It needs a UEFI_TARGETS variable plus build and install steps in debian/rules (guarded by a pkg.rustc.nouefi build profile), a libstd-rust-dev-uefi binary package, and a .install file listing the rustlib paths. To keep this moving rather than wait on a round of questions, I will go ahead and open a merge request that follows the precedents already in place, and I will of course adjust it to whatever you prefer. I plan to build against two assumptions: 1. The package name follows the rust standard-library convention of using the target token, which gives libstd-rust-dev-uefi. I am not reusing the existing -efi suffix, since that one is used arch:any as a sibling architecture, whereas these libraries are arch:all. 2. The package is arch:all with Multi-Arch: foreign, matching -bpf, so that uefi follows the same arch:all versus arch:any decision as the other rust target standard libraries rather than diverging from it. If you would prefer a different suffix or a different architecture handling, say so and I will amend the merge request. The diff is small. Greg Lamberson
