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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f32b26f.8050...@debian.org