Re: armelfp: new architecture name for an armel variant

[Paul Brook <paul@codesourcery.com>]

> > 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 
package.

Paul