Any ideas why people are relying on distro packaged Rust for development instead of rustup? For Rust it feels weird making development choices around several year old versions of the language.
So, if you are developing something you want to see packaged in distros, it needs to be buildable with the tool versions in the distro's repositories.
(Not just rustup- Debian requires repackaging Cargo dependencies so that the build can be conducted offline entirely from source packages.)
This feels more like a CI thing for the QEMU project and I’m sure solvable by using rustup or a trusted deb repo that makes the latest tool chain available on older Debian platforms.
As for Debian itself, for toolchains it really should do a better job back porting more recent versions of toolchains (not just Rust) or at least making them available to be installed. The current policy Debian is holding is really difficult to work with and causes downstream projects to do all sorts of workarounds to make Debian builds work (not just for Rust by the way - this applies to C++ as well). And it’s not like this is something it’s unfamiliar with - you can install multiple JVM versions in parallel and choose a different default.
Lots of QEMU users use it through their downstream distros. We even recommend that if you're using QEMU in a way that you care about its security then you should use a distro QEMU, because the distros will provide you timely security fix updates. Sure, we could throw all that cooperation away and say "tough, you need to use up-to-the-minute rust, if that's a problem for distro packagers we don't care". But we want to be a good citizen in the traditional distro packaging world, as we have been up til now. Not every open source project will want or need to cater to that, but I think for us it matters.
That doesn't mean that we always do the thing that is simplest for distros (that would probably be "don't use Rust at all"); but it does mean that we take distro pain into account as a factor when we're weighing up tradeoffs about what we do.
Out of curiosity though, have you explored having your own deb repo instead? I would trust QEMU-delivered security fixes on mainline far more than the Debian maintainers to backport patches.
As an upstream project, we really don't want to be in the business of making, providing and supporting binary releases. We just don't have the volunteer effort available and willing to do that work. It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams.
> QEMU has historically not made particularly timely security fixes either on mainline or on branches
> It's much easier for us to stick to making source releases, and delegate the job of providing binaries to our downstreams
Am I correct that this is essentially saying "we're going to do a snapshot of the software periodically but end users are responsible for applying patches that are maintained by other users as part of building"? Where do these security patches come from and how do non-Debian distros pick them up? Are Arch maintainers in constant contact with Debian maintainers for security issues to know to apply those patches & rebuild?
[1] and also to stable branches, but not day-of-cve-announcement level of urgency.
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.
That said we will probably switch to Debian rustc-web soon, and bump the lower limit to 1.75 or so.
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
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.
What Debian has is not a "stranglehold" but an ideology, and Debian continues to matter to (some) upstream projects because lots of users identify with Debian's hyperconservative, noncommercial ideology.
Your complaint is basically, "it's too bad that the userbase not sharing my values is large enough to matter".
> Your complaint is basically, "it's too bad that the userbase not sharing my values is large enough to matter".
Arch and rolling releases have about the same market share as Debian. Indeed, ironically, Debian's widespread adoption is seen primarily in the enterprise space where it's free as in beer nature and peer adoption is a signal it's a suitable free (as in beer) alternative to RedHat. Without Ubuntu's popularity a while back making Debian not so crazy an idea, I think "Debian" philosophy would not have anywhere near the adoption we see in commercial environments.
Does Debian have a stranglehold? AFAIK every other distro does the same thing, and all of them for good reasons.
Most toolchains don't have as much churn as Rust.
Java in Bookworm installs JDK 17 which is three years old at this point. Java itself is on 23 with 21 being an LTS release.
This means that upstream users intentionally maintain an old toolchain just to support Debian packaging or maintain their own deb repo with newer tools.
You’re confusing cause and effect. People aren’t migrating because Debian packaging lags so badly, not because there aren’t improvements projects would love to otherwise use.
What churn? A release every 6 months? Unlike many others, toolchains (i count nodejs and co here) rust only need one toolchain because latest rustc always able to compile older rust code.
Now compare rust releases to this: https://gcc.gnu.org/releases.html
That is not true. Adding any public method to any impl can cause existing working code not to compile, and Rust adds new methods to the stdlib all the time.
trait OptionExt {
fn get_or_insert_default();
}
impl<T> OptionExt for Option<T> {
fn get_or_insert_default() {}
}
fn main() {
Option::<()>::get_or_insert_default();
}
If Rust decides that it no longer supports compiling on x86, or if it starts depending on a version of LLM that no longer runs on a supported architecture, Debian must fix that for their users. That leaves the curl2bash installers that are popular with fast moving tools and languages useless for long term stability. The same goes for crates, which can be pulled at any time for almost any reason and break compiles.
Then there are other setups distros can choose to support, like having update servers/package repositories for updating servers that aren't allowed to connect to the internet or are even air gapped. You can't save rustup to a DVD, but you can take a copy of the Debian repository and update air gapped servers in a way that leaves a permanent trace (as long as you archive the disks).
Not all distros have this problem. In theory the Rust people could set up an apt/repository Debian users can add to get the best features of a package manager and the latest version, and distros like Arch/Gentoo don't bother with the stability guarantees most distros have.
Qemu can ignore these requirements and opt into not being packaged into distros like Debian or Ubuntu or Fedora or RHEL or Oracle Linux. That'd cost them a lot of contributions from those platforms, though, and may cause a risk of the project being forked (or even worse, end up in the ffmpeg/avconv situation).
Then you stop publishing new versions of the toolchain for x86 releases of the distro? I fail to see the problem. Nothing prevents you from not making a newer version of the toolchain available. Indeed, that's the default.
> The same goes for crates, which can be pulled at any time for almost any reason and break compiles.
I never said you have to extend this by making all versions of crates available. You can freeze the crates using the same mechanism to redirect Cargo as they do today.
I'm going to ignore the rustup stuff as I wasn't proposing rustup be used for building the base Debian image itself - that was a comment more about the environment QEMU itself can advocate for for people building it & leaving it to the distros to solve their own packaging problems.
I don't know if others have run into the same thing, but it's why I'd trust Gentoo's packaging more.