On Sun, Nov 24, 2024 at 04:22:18PM +0000, Andrew M.A. Cater wrote: > > > > > B) bump the i386 baseline in Debian to require SSE2, and stop disabling SSE2 there in rustc > > > > > > > > As suggested by Chris, and a popular opinion/request in general. > > > > > > > > > > Considering that for Trixie we won't have an i386 installer, particularly: > > > it seems evident to me that as more software depends on Rust, less of it > > > will be usable on i386 (and possibly something like armhf in due course.) > > > This whether or not we rebase the hardware requirements for an architecture. > > > > Sorry, I don't get it. > > > > Hi - sorry I might have conflated more than one thing That's what I thought :) > 1. Rust itself is fast-moving and difficult to package/deal with. There's a > couple of threads on LWN.net on this at the moment. There's a further > distinction between Rust in general and Rust in the Linux kernel itself - > which is further behind Rust head development. In general: Support in > Debian is difficult for fast-moving software without guaranteed backward > compatibility long term. > > 2. Upstream Rust doesn't particularly care about 32 bit i386 - so it's a > Debian thing to try and produce appropriate binaries including Rust wherever > they are. Yeah. Bumping the i386 baseline will certainly only fix some of the problems, talking here not just about Rust but in general. I agree that i386 is not a priority for most upstreams and the baseline doesn't matter in many of those cases. > 3. There are packages including Rust that can't be built on 32 bit / can't be > built on some of Debian's ports. Firefox is one, I think - and there's the > general problem that some larger packages like libreoffice are marginal on > some architectures, without considering Rust. That situation can only get > worse with time. > > 4. The consensus seems to be that i386 in Trixie won't have an installer > built for it - there's no kernel support in the most recent kernels. The > architecture is being maintained primarily for compatibility with older > software (also the reason for no time_t64 transition on i386). > > 5. If we're moving hardware baselines for the sake of Rust (or any other > software on this architecture) it's already too late. I think it's something like that: 1. Considering the likely future path for the i386 Debian arch we should mostly care about libraries and maybe agressively disable building leaf executable packages at some point. I don't remember anyone suggesting to instead make a closed "allowlist" and drop everything else, and that could be an interesting idea, but maybe it's too early for it. 2. It seems that we won't be able to maintain everything we want for i386, and will need to drop random things after they are no longer possible to maintain there. 3. Still, we may want to do some things we can do in order to maintain more "libraries" for longer. So yeah, it may be possible that the people responsible will say "it's not possible for us to keep Rust on i386". But it's unclear if it's worth it to keep it or not in the possible future "legacy apps support only" i386 if it is possible to keep it. -- WBR, wRAR
Attachment:
signature.asc
Description: PGP signature