bug-gettext
[Top][All Lists]
Advanced

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

Re: [bug-gettext] Endianness of .mo files


From: Santiago Vila
Subject: Re: [bug-gettext] Endianness of .mo files
Date: Fri, 16 May 2014 11:33:52 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, May 16, 2014 at 03:58:22PM +0900, Daiki Ueno wrote:
> After reading the discussion, I was left with a question.
> 
> When the GNU gettext infrastructure is used, upstream tarballs include
> *.gmo files, which could have been generated in a different byte-order.
> Does the recent Debian build system forcibly regenerate them on package
> building?

In this context, the "Debian build system" is whatever the maintainer
decided to put in debian/rules. There is not a policy of removing .gmo
files as such, so sometimes we keep them, and sometimes we remove them.

When any of the .po files is modified, for example, the build system
detects a difference in binary files which may not be represented in
the Debian diff. In this case we either repackage the original tar.gz,
or, preferably, remove .gmo files at build time.

> > I wonder if it would be possible to have some sort of option which I
> > can pass to ./configure to achieve this behaviour so that modifying
> > msgfmt.c directly was not needed.
> 
> Yes, it could.  But I doubt if it really helps multiarch packaging.

Well, there is also the issue of "reproducible builds"

https://wiki.debian.org/ReproducibleBuilds

where a msgfmt having always the same endianness certainly helps to
achieve such goal.


In either case, this ./configure option would be really to help me,
who has to keep the patch in every release of the Debian gettext
package. The patch is very small indeed and this is not a big problem,
but of course, we do much prefer to have debian/patches/* in the
Debian source to be as empty as we can,

Currently, the Debian gettext 0.19 package will have three patches:

* This one about endianness.
* Another one to disable java in gettext-tools/src/urlget.c (maybe I should
  ask for a configure option here as well).
* The one that updates [...]/hello-c++-kde/admin/config.{guess,sub}.
 
I would be very happy if we could reduce this to zero patches some day.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]