On Sat, 2022-07-16 at 18:03 +0300, Adrian Bunk wrote: > On Sat, Jul 16, 2022 at 03:54:21PM +0200, Ben Hutchings wrote: > > On Sat, 2022-07-16 at 06:23 +0300, Adrian Bunk wrote: > > > On Fri, Jul 15, 2022 at 01:51:21PM +0200, Ben Hutchings wrote: > > ... > > > This is not limited to i386, it is also quite relevant for embedded arm > > > where new products using 32-bit cpus are still being developed today. > > > > New products can build user-space with 64-bit time_t. They don't have > > Debian's ABI constraints. > > ... > > Many people want to use Debian in embedded, and there are people > who would like to have a Debian release architecture that is armhf > with 64-bit time_t. > > Not sure whether anyone will actually do the effort, but this is the > most likely 32-bit release architecture we will still have after 2038. That may yet happen. Steve McIntyre started, but didn't have time to complete it. Maybe as the deadline gets closer there will be more resources available for this. :-) > > > > This is not to say that i386, or 32-bit architectures, should be > > > > dropped as a whole. We've supported installing a 64-bit kernel on i386 > > > > since etch, though it now requires adding amd64 as a foreign > > > > architecture. I do think that at some time soon we should stop > > > > releasing kernel binaries or an installer for i386. > > > > > > Speaking with my i386 porter head on, I would rather ask for moving i386 > > > to ports than dropping all support for i386 hardware. > > > > I think we have the following use cases for i386 now: > > > > 1. PCs with 64-bit CPUs, with i386 as the primary Debian architecture. > > This might be the result of keeping an i386 installation through > > hardware upgrades. > > 2. PCs with 64-bit CPUs, that need to run i386 binaries that can't be > > rebuilt for amd64 (proprietary, or unportable). They might have > > either amd64 or i386 as the primary Debian architecture. > > 3. PCs with 32-bit CPUs. > > > > Moving i386 to ports would clearly serve use case 3 better than > > dropping the kernel and installer. Keeping i386 as a release > > architecture, but without a kernel and installer, seems to serve use > > cases 1 and 2 better. > > > > What's not clear is how many users fall into each of these use cases. > > ... > > What problem is building i386 bookworm kernel binaries causing for you > that are not present on other architectures like armhf or s390x? Good question. I think the problem is that those i386 binaries will mostly work on 64-bit PCs and users will wrongly expect that they are fully supported. But various features aren't implemented (in the kernel) or aren't available (architecturally) to a 32-bit kernel on a 64-bit CPU. I suppose this can be mostly dealt with by sticking warnings around the place: - Installation manual for i386 - Release notes for i386 - Package installation (debconf) - Kernel boot (log and taint flag) Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part