Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
On Sun, Feb 12, 2012 at 08:00, Carsten Hey <email@example.com> 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, which indicates a package that is installable on
> all little endian architectures.
> * bigendian, 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?