[Pkg-rust-maintainers] Bug#1102311: Bug#1102311: Bug#1102311: Bug#1102311: rust-src is missing Cargo.lock

[Fabian Grünbichler]

On Wed, Apr 16, 2025, at 8:50 PM, Matt Corallo wrote:
> On 4/14/25 2:15 PM, Fabian Grünbichler wrote:
>>>> That's not really possible/in scope for Debian..
>>>
>>> I don't see why? Debian already ships libstd-rust-dev-windows as well
>>> as gcc packages for tons of
>>> random targets, but really I guess this is just #989844, then.
>> 
>> most such targets don't really have a clear mapping to Debian architectures,
>> and also no use case within Debian.
>
> I'm a bit confused, does gcc-mingw-w64 or arm-none-eabi-gcc not have a 
> use within debian? They're 
> used by tons of people to build binaries for other systems from an open 
> source root of trust that 
> cares about deterministic builds. We happen to use the Debian rust 
> packages for the same, and that 
> seems like a pretty common usecase given how prevalent use of the 
> arm-none toolchains are.

they definitely do have a use case *on Debian*, which is different than
having one *within Debian*.

for rustc in particular, I made the choice to drop the windows targets
for now, because there aren't many people using Debian's rustc for actual
development, its main use case (given upstream's and the general ecosystem's
volatility) is for building packages for/in Debian, not arbitrary software
on Debian. I am happy that it works for you, and starting with Trixie, you
should be able to do so for almost any target supported by upstream via
-Zbuild-std, provided you don't want to use only packaged crates at the same
time - because the shipped Cargo.lock file is the original upstream one, and
the (patched) vendored crates (which would not match that file) are only
contained in the source package, and not in rust-src in any case. Fixing this
is basically impossible, because we don't build those other targets in Debian,
so the set of patched vendored crates would often break arbitrary targets
without us noticing.

if there is a strong case made for a particular target and it is possible to
add it to the packaging without regressing other goals like package
reproducibility, I will consider adding them. in particular, the WASM targets
will likely continue to be supported and updated with upstream developments,
because I expect those to become required sooner rather than later by other
packages (whether for web UI stuff written in Rust, or plugin or container
runtimes that use WASM as bytecode format).

>> the windows one is no longer built (by
>> default, the support is still there in case somebody needs it) because the
>> windows-cross toolchain it uses produces unreproducible output.
>
> Huh, interesting. We haven't had that issue, though of course had to 
> fight with `RUSTFLAGS` quite a 
> bit to get there.

there's one more issue with rustdoc that keeps the full rust toolchain package
set from being reproducible, but everything but the -doc packages is now that
the windows stdlib is dropped, and I hope to get rid of that remaining issue
during Forky.