On Mon, Apr 30, 2012 at 22:21, Goswin von Brederlow <goswin-...@web.de> wrote: > 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. >
/usr/lib/<tuple>/package/ is more natural with Autotools and CMake, which I prefer to use. > 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. > Yes, detecting endianness at compile time and setting substvar is easy, but again if those packages are arch:any, then they'll actually consume a lot of space on our mirrors (discussed at -devel before). >> 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. > If we want to reduce the mirror space consumed by such a package, building arch:all package is a straightforward solution without modifying archive management software and dpkg/apt, but it's again not a good choice because we have to keep using binary upload mechanism (or the maintainer will be required to patch the software so it can generate both be/le data during a single buildd run). > 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 I agree on your opinion. It's much better than nothing. But we do need to discover possible solution for Wheezy+1 or even Wheezy+2, don't we? :-) -- Regards, Aron Xu -- 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/CAMr=8w5uu+ojvtfhp-7op6g4ijjdj7pdsi+n5jnqt_r3kt0...@mail.gmail.com
