Daniel P. Berrangé <berra...@redhat.com> writes: > On Sun, Oct 27, 2024 at 10:01:26AM +0300, Michael Tokarev wrote: >> I think this is the wrong direction (ie, backwards). >> >> Sacrificing current code to be compatible with old stuff feels wrong. >> Especially for really old, like rustc in debian bookworm. >> >> bookworm has rustc-web (and a few related packages) which is regular >> rustc version 1.78, just renamed. It is regular bookworm, not backports. >> It has some packages disabled (compared to regular rust) and is a hack, >> but it exists and can be used for now (dunno if it is sufficient for >> qemu though). >> >> Also debian has backports mechanism, which also can be used for qemu - >> I can try back-porting regular rust (and llvm) to bookworm. >> >> I think this is a better way (at least a way forward) than trying to >> move backwards. >> >> But generally, what is the reason to support debian stable? I understand >> the CI thing, - we need a way to test stuff. For this, I'd say a better >> alternative would be to target debian testing (currently trixie), not >> debian stable. > > The stable distros are what our community of contributors are usually > using, as few people want non-released bleeding edge distros as their > primary development platform. > > Custom installing latest upstream pieces is not a user friendly position > to take. Occassionally it is unavoidable, but it is something to be > avoided wherever practical.
At least rustup makes this reasonably easy for the rust bits. We do rely on the excellent Debian backports for getting QEMU quickly into testing images but I was assuming we would have trixie before --enable-rust became mandatory so I'm not too worried if bookworm is the outlier for old versions. > > With regards, > Daniel -- Alex Bennée Virtualisation Tech Lead @ Linaro
