Re: Defaulting to i686 for the Debian i386 architecture
+++ 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/
Reply to: