[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

The following paragraph could be (changes are marked in a wdiff like
| In the main debian/control file in the source package, this field may
| contain the special value all, the special architecture wildcard{+s+}
| any{+ or endian (which matches littleendian and bigendian)+}, or
| a list of specific and wildcard architectures separated by spaces. If
| all{+, endian+} or any appears, that value must be the entire contents
| of the field. Most packages will use either all or any.

 [1] The dash before endian to make it more readable is omitted to make
 the resulting architecture wildcards (see Debian Policy, section
 11.1.1) more consistent with the existing ones.

Reply to: