On Sun, Oct 27, 2024 at 8:02 AM Michael Tokarev <m...@tls.msk.ru> wrote: >i > 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).
Thanks for pointing it out! It is indeed better, however it does not support mipsel. > 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. Basically: it is not too hard and it can be reverted without much hassle once we stop supporting Debian 12 in general. Also, the next-lowest version (in Ubuntu 22.04, which has 1.75.0) would still have some relatively invasive changes, for example patch 11. We'll always need some workarounds until all supported distros have rustc 1.77.0. Paolo
