On Tue, 20 Jan 2009 21:00:25 +0100 Loïc Minier <lool@dooz.org> wrote: Adding a CC for debian-i18n (context for debian-i18n) > n 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). > > 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. So duplicate all .mo files into two places? How can that be a sane alternative to the tiny overhead of the current wrapper? > 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. > > On Tue, Jan 20, 2009, Neil Williams wrote: > > Is there any actual evidence of a problem with the current situation? > > I see two main issues: > - the endianess of files in the archive is actually random > - I would expect the most common endianess to be the little endian one > since maintainers mostly upload packages for amd64/i386; this means > that the slow big endian arches usually get to pay the hit Is it worth changing though? It seems like excess pedantry to me. Are there any packages that actually fail to show the translations because of the endianness of the .mo file? (That would presumably be a bug in gettext.) Has anyone been able to measure the performance hit? I can't see that it is worthwhile converting foo-data_1.2.3_all.deb into 12 versions of foo_data_1.2.3_$arch.deb where the only difference is the endianness of the .mo files. Alternatively, what is the point of duplicating /usr/share/locale/ to have two copies in every package that contains gettext translations ? > > Changing the endianness of a .mo normally requires the original .po and > > the msgfmt binary which means a runtime dependency on gettext *AND* the > > need for the original source. > > I understand you're replying to the runtime conversion proposal. > > cd /usr/share/locale/fr/LC_MESSAGES && \ > msgunfmt <apt.mo | msgfmt - -o - | md5sum apt.mo - > b6e3086cefe18ef53c961187cf22cead apt.mo > b6e3086cefe18ef53c961187cf22cead - > > are you saying that msgunfmt doesn't work when there's an endianess > mismatch? That would be surprizing. So is that to be done in the build or the postinst? Runtime would still need a dependency on gettext. Doesn't make any sense to "fix", at least to me. It makes even less sense when taken into the context of TDebs. Translator uploads of TDebs should not need to be put through the buildd, that is part of the gain from using TDebs in the first place. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgp_cQs1GvS7d.pgp
Description: PGP signature