On Tue, Jan 20, 2009 at 11:02:46AM +0100, Loïc Minier wrote: > (moving to -devel with a reply-to) > > On Tue, Jan 20, 2009, Fabian Greffrath wrote: > > Running the 'file' command on > > '/usr/share/locale/de/LC_MESSAGES/epiphany.mo' reveals a "GNU message > > catalog (little endian), revision 0, 920 messages". > > > > The 'little endian' part is fine, since this is an i386 system. But > > the file is content of the epiphany-browser-data package which is > > supposed to hold the architecture-independent data files for > > epiphany-browser. Since this package is also a dependency of > > epiphany-browser on powerpc (i.e. big endian), how is it possible this > > combination works resp. does it relly work on powerpc? > > > > I am asking because I am currently working on the audacity package and > > would like to split out the content of /usr/share into an arch:all > > audacity-data package, when I just encountered this issue. > > The files will work on both little endian and big endian systems, but > there's a performance hit when the endianess differ (as the file can't > be used directly when it's mmap-ed).
How much performance loss are we looking at ? If it's a few %, is it that important? There are already various things that are little-endian even on big-endian architectures, beginning with the ext3 filesystem. > It's a bug, but it's not clear to me how we could fix this while not > losing too much space. > > Perhaps we could have a tool converting .mo files from one endianess to > the other and ship the two versions in epiphany-browser-data, then > patch gettext to loop up files in an endianess specific location first > e.g. gettext would look in /usr/share/locales/big-endian or > /little-endian first (depending on endianess), then in > /usr/share/locales. > > I'd rather not implement anything specific in epiphany-browser, it > would be best to discuss this more widely and come to a generic > solution for all arch: all packages. IMHO, the real issue is that depending on the arch which the arch:all package is built on, the resulting file's endianness will change. Maybe msgfmt should be patched to always generate the same endianness by default. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
