Re: Deciding new arm EABI port name

["Martin Guy" <martinwguy@gmail.com>]

> "arm", "i386", "m68k" are shorthands. Please have a look at
> dpkg-architecture sources:
>
>     if ($os eq "linux") {
>         return $cpu;
>     } else {
>         return "$os-$cpu";
>     }
>
> Next, have a look at ostable and cputable files. After that I think it
> should be clear why current dpkg-architecture limits our choices.

Aha. Thanks.

It does seem that the current Debian structure is creaking at having
to cram different os-cpu-libc-abi-endian combinations into a single
namespace ("$cpu" above). What was originally conceived as a way of
supporting different hardware is now being used to support different
ways of using that hardware: different "$cpu"s now mean binarily
incompatible compiled object formats (caused by difference in OS, CPU,
libc, endianness or ABI).
The different OS issue has already been split off as "prefix-" to
support hurd and freebsd.

This may be enough - mipsel and armeb seem to be happy enough - but it
still seems to me that, within the existing Debian scheme, poking
[gnu]eabi into the "os" namespace instead of the "cpu" namespace is an
even stranger choice. It's not as if EABI binaries are os-independent.

At this point it's no longer "just a name", but raises one of two questions:
- do we need to re-evaluate the whole issue of
os-cpu-endianism-abi-floatingpointuse-libc, giving unspecified fields
cpu-dependent defaults (or using shortform alises) that will let the
existing names continue unmodified?
or
- which of the existing inappropriate namespaces (os or cpu) do we
hijack to support a new ABI for arm?

   M