[vlovich123]

To be clear. I’m not criticizing the position the QEMU project is in. I recognize you have to work with Debian here. I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way.

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.

[pm215]

I think that trust would be somewhat misplaced -- QEMU has historically not made particularly timely security fixes either on mainline or on branches. To the extent that our stable-branch situation is better today than it was some years ago, that is entirely because the person who does the downstream Debian packaging stepped up to do a lot more backporting work and stable-branch maintenance and releases. (I'm very grateful for that effort -- I think it's good for the project to have those stable branch releases but I certainly don't have time myself to do that work.)

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.

[vlovich123]

These two statements to me seem contradictory:

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

[pm215]

Security patches are usually developed by upstream devs and get applied to mainline fairly promptly[1], but you don't want to run head-of-git in production. If you run a distro QEMU then the distro maintainers backport security fixes to whatever QEMU they're currently shipping and produce new packages. None of this is particularly QEMU specific. There's a whole infrastructure of security mailing lists and disclosure policies for people to tell distros about security bugs and patches, so if you're a distro you're going to be in contact with that and can get a headsup before public disclosure.

[1] and also to stable branches, but not day-of-cve-announcement level of urgency.

[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

[jefbyokyie]

> I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way.

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

[vlovich123]

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

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.

[yjftsjthsd-h]

> I’m more frustrated that Debian has such a stranglehold on packaging decisions and it effectively refuses to experiment or innovate on that in any way.

Does Debian have a stranglehold? AFAIK every other distro does the same thing, and all of them for good reasons.

[vlovich123]

Ubuntu and Arch are about equal market share penetration for the desktop from what I researched with other and steam deck being the main dominant categories. So ignoring corp fleet deployments, I'd say Arch and NixOS have stolen quite a bit of market share from Debian-based systems in terms of end-user preference. But yes, Debian does still have a stranglehold because corp $ are behind Debian-style deployments.