Re: new rustc targets that don't match Debian architectures
On Fri, Nov 28, 2025, at 8:27 AM, Simon Richter wrote:
> Hi,
>
> On 11/28/25 2:24 PM, Adrian Bunk wrote:
>
>>> There is significant established practice for using arch:all in this
>>> way.
>
>> Which is not particularly relevant when building an architecture
>> ecosystem in arch:all would prevent providing security support.
>
> The way I understand it, the problem isn't the arch:all, but the static
> linking.
that's also my impression. if one of the shared libraries used by rustc/cargo
has an issue that requires an incompatible bump, that likely means the rust
bindings need adaptations as well, so a binNMU likely won't cut it anyway.
> [..]
>
> Longer term, since we're picking up a lot of software with no API or ABI
> stability guarantees, it may be a good idea to have a way to encode
> API/ABI information in a way that is equivalent to modifying the package
> name, but can be automated better (e.g. generating Build-Depends from a
> Cargo.lock).
well, for Rust crates we already do this along semver API - hence the
annoying number of virtual packages and dependencies, for which we always
get flak because it deviates from the usual Debian norms :-P
of course that doesn't really help for a security fix, because you'd want
to backport a minimal change there, and you can't do downstream semver
bumps, so you need to manually adjust versioned deps on the rdep side, or
manually shepherd the builds to ensure nothing gets built prematurely,
which is also annoying.
thankfully in practice you'd usually only need to do:
- build fixed package that has issue
- rebuild all packages linking it
so you only need for that first build to be done and installed..
Reply to: