Re: Endianness of data files in MultiArch (was: Please test gzip -9n - related to dpkg with multiarch support)
On 08/02/12 17:22, Aron Xu wrote:
> 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. AFAIK some maintainers
> are not aware of endianness issues in their packages and then just
> ignored it (not sure how many, but if any of them are discovered it
> should lead to RC bug).
Hopefully Jakub Wilk's automatic checks for conflicting files
<http://people.debian.org/~jwilk/multi-arch/> will already be picking
this up, in cases where the less-used-endianness architectures aren't
broken already.
If the less-used-endianness architectures are already broken, that's
also a bug (potentially an RC one), just like code that compiles but
doesn't work on a particular endianness due to other assumptions - and
if nobody has noticed it yet, presumably the package doesn't have any
users (or regression tests) on those architectures.
> It would be great to have some mechanism to
> handle such kind of problems in Debian, to avoid forcing those data to
> be placed into arch:any package.
If the right endianness is critical: libfoo:i386 Depends:
libfoo-data-le, libfoo:powerpc Depends: libfoo-data-be, both data
packages arch:all, data files in /usr/share/foo/le and /usr/share/foo/be
respectively?
Or just make sure the data has an endianness marker, and enhance the
reading package to do the right byteswapping based on the endianness
marker - e.g. this has been discussed for gettext, which ended up just
writing out the same endianness on all platforms. Many formats
(particularly those that originated on Windows) are always
little-endian, and big-endian platforms reading them just take the minor
performance hit; formats that respect "network byte order" have the
opposite situation.
S
Reply to: