[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Little endian /usr/share/locale/* files in epiphany-browser-data

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

Attachment: pgpHs_LqwEni0.pgp
Description: PGP signature

Reply to: