Aron Xu <happyaron...@gmail.com> writes: > But what if I endianness does matters for those gettext .mo files? > Installing them as libfoo-translations-be and libfoo-translations-le > will need some change in gettext support of those > applications/libraries, that is finding mo files in alternative paths, > and choosing the right one when being built (cross or not) and run > (host or qemu).
Yes it does. Or maybe not. Lets talk about the general case instead of gettext (gettext uses /usr/share/... so they must be arch independent). With libfoo being in /usr/lib/<M-A tuple>/ any endian dependent data should be in /usr/lib/<package>/<M-A tuple>/ or /usr/lib/<M-A tuple>/<M-A tuple>/ (sorry, did we pick one of them as standard yet?), which is usualy a configure option. When the files are moved into libfoo-data-be then you can put links in /usr/lib/<package>/<M-A tuple>/ or /usr/lib/<M-A tuple>/<M-A tuple>/ to link to /usr/lib/<package-data-be/le>/. > Apart form (possibly) patching the software, marking the library as Not the library, only the data files. > M-A:foreign is questionable. How do we specify dependencies in > d/control? If libfoo requires either libfoo-data-be or libfoo-data-le > on different architectures, do we really want to hard code which > architecture to depend on which package manually? For the moment I don't see any other choice. If this is a frequent problem then some dpkg support could be added or some debhelper tool. Detecting the endianness at compile time and setting a substvar would be relatively easy even now. > Generating data files for both be and le then making it an arch:all > and M-A:foreign package is not a solution for all maintainers, as this > requires to patch the software which upstream are tend to reject of > inclusion in many cases. Generating such data files in maintainer > scripts is another thing I hate because I believe these data meant to > have checksum stored in the package file list so that users can verify > its integrity when needed. There is no one solution for all maintainers. At the moment and given the closeness of the freeze I would just do whatever works for now. If that means big and little endian flavours of the library have to conflict (libfoo-data-be conflicts libfoo-data-le) because the path can't be untangeled then I would still think that would be better than no multiarch support at all. The most common case is amd64+i386 and adding armel is probably the next common. So most multiarch users would be ok. MfG Goswin -- 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/87zk9ts3k9.fsf@frosties.localnet