Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)

[Aron Xu <happyaron.xu@gmail.com>]

On Sun, Feb 12, 2012 at 08:00, Carsten Hey <carsten@debian.org> wrote:
> * Aron Xu [2012-02-09 01:22 +0800]:
>> Some packages come with data files that endianness matters, and many
>> of them are large enough to split into a separate arch:all package if
>> endianness were not something to care about. ...
>
> Debian Policy, begin of section 5.6.8:
> | Depending on context and the control file used, the Architecture field
> | can include the following sets of values:
> |  * A unique single word identifying a Debian machine architecture as
> |    described in Architecture specification strings, Section 11.1.
> |  * An architecture wildcard identifying a set of Debian machine
> |    architectures, see Architecture wildcards, Section 11.1.1. any
> |    matches all Debian machine architectures and is the most frequently
> |    used.
> |  * all, which indicates an architecture-independent package.
> |  * source, which indicates a source package.
>
> Possible addition to solve your problem:
>   * littleendian[1], which indicates a package that is installable on
>     all little endian architectures.
>   * bigendian[1], which indicates a package that is installable on
>     all big endian architectures.
>

I agree this will help a lot, and the endians may be shortened as "le"
and "be". But there's still file collision if maintainer doesn't
install them in different paths, but that's another story.

debian-policy people, would you like to take this idea? What's the
steps to make this (possibly) happen?


-- 
Regards,
Aron Xu