On 2023-06-06 11:45 +0100, Simon McVittie wrote: I missed most of this conversation due to being on holiday, so just catching up now.
I hesitate to continue the i386-distraction thread because what's actually important is getting this transition underway on the other arches, particularly arm32 (hf/el). But at least one aspect seems to have been missed in the discussion so I thought I should point this out (and we can't easily move forward without a plan for i386 as dpkg defaults affect all arches unless we make explicit excetions). > When considering the future of i386, a factor that we need to bear in > mind is that there are two major use-cases for i386, with requirements > that sometimes conflict: > > 1. i386 as a fully-featured architecture that you can run independently > on 32-bit x86 systems from roughly the 2000-2010 era > > 2. i386 as a multiarch foreign architecture to run legacy binaries on > modern x86_64 systems > 2a. legacy native Linux i386 binaries > 2b. legacy Windows i386 binaries via Wine (which requires a somewhat > complete i386 Linux library stack) It is possible to have both these things, by treating this transtion as a new-ABI (i.e new architecture) transition, not a within-arch ABI transition. i.e we could keep the existing i386 for the gamers and have i386t64 (or whatever we call it) for ongoing use of i386 as a real OS. This seems to me the 'right' way to deal with this 'the two possible i386 ABIs are different but both useful in different ways'. That way we don't have to choose one or the other and everyone could be happy. If we do that for other arches too then it greatly simplifies the transition because we don't have to do a library transition at all. And bootstrapping an arch is dramatically easier than it used to be thanks to rebootstrap. However there are major disadvantages too. We'd end up quite a few new arches for at least one release, and we'd spoil the upgrade path for people who would like their existing arch to just move with the times. We'd have to think up and agree new triplets and get them into toolchains, and fix architecture exceptions in packaging. There is no appetite for this (new triplet) work outside debian, but if we do it right people will probably agree/follow (because it is technically correct). My assessment is that this is just as much work as doing the transition in-arch, and will probably take longer due to the external co-ordination needed. Given all that I don't think the option of 'new arch for everyone' makes much sense. Which gets us back to 'new arch for i386, other arches do in-arch transition'. So we still get to do the library transition anyway. But we _could_ also make a new i386t64 arch to enable i386-the-real-OS a post 2038 future. Does anyone care enough about that to do the work? If so I think we should let them. This is the only i386 use-case I care about, but in practice I'm only going to care about it for a few more years which will be served by the current releases so I don't think I'm going to bother bootstrapping the new version. Happy to help others though. Just thought this was worth bringing up because whilst the existing 'i386' arch has to choose one ABI or another, nothing stops us from having both variants in the archive if we want them enough. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: PGP signature
