Re: armelfp: new architecture name for an armel variant
> > The tricky-bit here is that instruction-set extensions (VFP3, thumb2,
> > NEON) and instruction set versions (v4, v5, v6a, v7) can also be
> > incompatible in the sense that they won't run on hardware without
> > those features. But I really think we should try to deal with that by
> > correctly decorating ELF headers and making sure that the loaders and
> > dpkg 'DTRT' in terms of selecting compatible stuff. Not create an arch
> > for every combination.
> But then doesn't that mean that everything is "armel", so we never have a
> hope of having Debian officially support more than one combination?
Only if you assume a single set of builds per architecture.
There are several ways to allow different variants within the existing
architecture port. Ranging from third party repositories, though libc6-i686
type hacks to a new dpkg field to distinguish different builds of the same