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

[Fabian Grünbichler]

On Fri, Apr 17, 2026, at 11:05 PM, Jonas Smedegaard wrote:
> Quoting Fabian Grünbichler (2026-04-17 18:15:25)
>> Control: severity -1 wishlist
>> Control: tag -1 +moreinfo
>> 
>> On Fri, Apr 17, 2026, at 9:18 AM, Jonas Smedegaard wrote:
>> > Source: rustc
>> > Version: 1.94.1+dfsg1-1~exp3
>> > Severity: grave
>> 
>> I am not sure what this severity is supposed to mean, given the lack
>> of justification ;) Downgrading accordingly, but I am willing to
>> reconsider if you provide a reason.
>> 
>> > In package rust-src, /usr/src/rustc-1.94.1/Cargo.lock and
>> > usr/src/rustc-1.94.1/library/Cargo.lock are locked at crate
>> > versions unsatifiable in Debian, e.g. rustc-demangle 0.1.26 and
>> > object 0.37.3.
>> >
>> > Also, /usr/src/rustc-1.94.1/library/std/Cargo.toml requires
>> > newer-than-Debian crate including object 0.37.1, and
>> > missing-in-Debian crates including dlmalloc and wasi.
>> 
>> This is intentional. rustc and libstd/libcore are not built using
>> packaged crates, so the code shipped in rust-src cannot either.
>> 
>> The purpose of rust-src is (at the moment) twofold:
>> - allow navigating into libstd/libcore sources for IDE and editor
>>   integration, e.g. via rust-analyzer (as per the package description)
>> - allow using `-Zbuild-std` when using *just the toolchain* (by
>>   pretending to be nightly rustc via RUSTC_BOOTSTRAP)
>> 
>> Neither of this requires matching rust-src dependency information
>> with packaged crates, the latter in fact would not work at all in
>> that case unless rustc packaging itself is switched over to use
>> packaged crates, which is not really feasible.
>> 
>> I hope this clears things up, if not - please clearly describe what
>> you want to do and what doesn't work, maybe we can find a solution.
>
> Thanks a lot for the elaborate clarification, and sorry that I was way
> too brief.
>
> Yes, it is fine with me to lower severity. What I was thinking but
> forgot to write was that the severity I set is intended only as a first
> proposal: I don't really understand the prupose of that package, and
> you are as maintainer of course free to lower as you see fit.
>
> Now, the reason I stumbled upon and reported the issue in the first
> place was that the binary package libstd-rust-dev-wasm32 had
> mysteriously gone, and when I tried to use wasm-package without it, it
> mentioned needing rust-src. After filing the bugreport I realized that
> the reason for the disappearance was simply a delay in building the
> arch-all part of the newly released rustc source package. Oxigraph now
> succesfully builds using wasm-pack again.

I can see how you ended up thinking that rust-src is broken, that message
is indeed confusing in Debian context! It points at the second use case
I described - rebuilding libstd for targets not packaged, or with
settings not matching the packaged version.

The wasm libstd was indeed late this time around (as was the bpf one),
because I forgot to upload a matching wasi-libc for the rustc upload.

> 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.

Fabian