[Pkg-rust-maintainers] Bug#1134157: Bug#1134157: rustc-src: impossible to satisfy crate dependencies

[Fabian Grünbichler]

Control: tag -1 +pending

On Sat, 18 Apr 2026 10:08:37 +0200 =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= <debian at fabian.gruenbichler.email> wrote:
> On Fri, Apr 17, 2026, at 11:05 PM, Jonas Smedegaard wrote:

> [..]

> > It sounds like there is no bug here at all. Feel free to close this if
> > that's how you see it.
> 
> I think I'll leave it open to track maybe finding a way to support
> -Zbuild-std in packaging context as well (e.g., to unlock some firmware
> building usecase in the future, that might require a custom libstd).
> 
> It's a bit of a tough nut to crack though, because there can only be one
> replacement for crates.io (which we already use for packaged crates), so
> we'd probably need to ship a copy of the vendored crates as part of
> rust-src, and adapt all the dependencies to be path dependencies, and so
> on.

It turned out that this is actually easier than I thought.

Starting with the next rustc upload, rust-src will ship a copy of the
few vendored crates needed to rebuild std/core/alloc. If you make them
available to cargo (i.e. by linking them into the fake registry), a lot
of build-std variants already work (some targets will of course require
extra setup or dependencies, like special linkers or LLVM bits).

Upstream will start doing that as well:

https://github.com/rust-lang/rust/pull/156196

and plans to later switch build-std over to automatically pick those up,
at which point even linking them into the registry would no longer be
required.