+++ Manuel A. Fernandez Montecelo [2015-09-29 12:27 +0100]: > 2015-09-28 23:34 Josh Triplett: > >Many distributions have already dropped that support, making it all the > >more valuable that Debian hasn't. I can certainly understand dropping > >i386 and i486, but i586 remains useful today precisely because of Quark. > >Deprecating old systems that don't get built anymore would seem > >perfectly reasonable; however, people buy these systems new today, and > >will continue to do so in the future. > > Maybe it would be a good idea to split the architectures, and have one > port for legacy-but-still-sold-or-useful i386 and move the current i386 > to only support newer, common-use i686 hardware.
It seems to me that this relates to a similar issue with armel, and previous consideration of 'partial architectures' for mips (and arm). like '586-ISA i386', armel is now a port used only on low-end hardware, but that hardware can still be bought new, primarily as NAS boxes. Debian is one of the last distros supporting this, which makes dropping it quite hard on those still using it. However there is a large fraction of the archive that is not very useful on such machines, and a part of the archive that is starting to need major work to keep building for such hardware at all. The main disadvantage of keeping around old arches is the effort involved in keeping software building/working on it when the rest of the world no longer cares. Having a mechanism for 'partial architectures' to keep only the relevant subset of the archive available for these machines seems like a good plan, useful for at least i386 and armel, and probably others. Because a debian arch refers to an ABI, not an ISA-variant, you can't easily use our existing architectures mechanism to have both 'i386' and 'i686' without breaking some fairly fundamental assumptions. Being able to have 'partial achitectures' which are actually different baseline ISAs (586, 686) (armv6, armv7) for one ABI is something that has been discussed many times, but no-one has ever cared enough to actually implement it. This is particularly relevant on mips, where inconsistent ISA changes over the years mean that make picking one 'base ISA' is very unsatisfactory, and they would like a way of having alternative ISA (not ABI) builds of a significant set of packages (anthing where speed actually matters, so libc, some core things and anything codec-related, at least). (The rasbian port could have done things this way and stayed within Debian for example, but it was easier to derive). Some details of a proposal for implemnting this are covered in section 2 of https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results It would need fleshing out some more to actually be complete. Nevertheless, if we implemented that, the question of how the subsetting is done remains (i.e which packages are/are-not available in the other 'flavour'). I wonder if we could re-use sections or components for some kind of suitable classification? Such a mechanism could perhaps also be used for the 'set of things that won't build on 32-bit arches any more' for example, which is closely related to the 'set of stuff that is useless on a NAS box'. I hope that wasn't too rambling to be useful... Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
