[vlovich123]

Sure, but then why does the mainline branch need to worry about supporting the rust that’s bundled with the last stable Debian release? By definition that’s not going into a distro (or the distro is building mainline with rusts latest release anyway).

Is it a precautionary concern that backporting patches gets more complicated if the vuln is in Rust code?

But then again Rust code isn’t even compiled by default so I guess I’m not sure why you’re bothering to support for old versions of the toolchain in mainline, at least this early in the development process. Certainly not a two year old toolchain.

[bonzini]

We already make an exception in that we don't support Debian bullseye (which is supported by the rest of QEMU until the April 2025 release), but not supporting Debian stable at all seemed too much.

That said we will probably switch to Debian rustc-web soon, and bump the lower limit to 1.75 or so.

[vlovich123]

I think I'm missing why you need to require using the toolchain bundled with the last stable Debian release vs having devs just rustup the latest version of the toolchain (or via a PPA [1] or however else they want to install it).

The current approach basically guarantees that you're always targeting a ~2-4 year old version of the toolchain and that feels like a particularly weird maintenance burden given how many workarounds you're putting in to do so.

[1] https://launchpad.net/~jonathonf/+archive/ubuntu/rustlang

[bonzini]

Because it's not about devs, it's about distro packagers. They are an extremely important audience for QEMU. As pm215 said above, we don't want to make their lives unnecessarily harder. For example Debian has the backports repository, and CentOS Stream has QEMU and Rust updates done by different teams.

Anyhow starting April (August release) we will be able to target 1.75.0 while being consistent with QEMU's (C-targeted) distro support policies, which is not that bad. Maybe newer than that depending on what Ubuntu 22.04 does between now and August.