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

[Neil Williams]

On Tue, 20 Jan 2009 11:02:46 +0100
Loïc Minier <lool at dooz.org> wrote:

> 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".

This is a "feature" of gettext which is common to all gettext
translations, it does not just affect epiphany. As such, the "issue"
affects thousands of packages in Debian - however, I don't think that a
"real-world" issue exists for Debian machines.

> > 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. 

For a long time in Debian, .mo files have been deemed to be
compatible with Architecture:all packages.

Indeed, in order to support architecture-dependent .mo files, various
build tools would have to be amended.

Emdebian currently uses:
my $endian = &get_endianness;
my $cross = (defined $endian) ? "--endianness $endian" : "";
push @cmds, "msgfmt $cross -o $pdir/$tmppo.gmo $pdir/$tmppo.po" if (! -f "$pdir/$tmppo.gmo");
push @cmds, "install -m 0644 $pdir/$tmppo.gmo ${topdirprefix}${tmppkg}${finprefix}${tmppo}".
	"${finsuffix}/${gpkg}.mo";

i.e. every .po file has to be manually run through msgfmt with an
explicit flag that sets the endianness or gettext just does what it
always does.

See http://manpages.debian.net/cgi-bin/man.cgi?query=em_installtdeb

> > 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?

gettext black-magic - i.e. a wrapper with a slight performance hit 

>  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.

It's a bug that Emdebian is seeking to fix within our own packages
because if we can avoid the performance hit whilst rebuilding we are
packages anyway, we might as well. However, the cost of "fixing" it is
SEVERE.

Splitting translation files into architecture-dependent packages has a
vast impact on the archive. The figures from Emdebian are not directly
comparable because we also split out individual locales into separate
packages but the increase in package numbers was deemed unacceptable
by ftp-master and I agree completely. There is no sane reason to
convert all .mo files into architecture-dependent files in Debian.

Debian TDebs will be Architecture: all

http://people.debian.org/~codehelp/tdeb/ch5.html#s5.1

>  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 .mo files can remain Architecture:all in Debian - those who need
the architecture-match can look at the Emdebian methods. On any Debian
machine, the penalty of using the current system is negligible.

-- 


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20090120/2e17e5be/attachment.pgp