Comment 8 for bug 978724

On Mon, May 20, 2013 at 02:40:12PM -0000, Martin Pitt wrote:
> Steve Langasek [2013-05-17 14:45 -0000]:
> > Regenerating the .pot file at package build time changes timestamps,
> > which means the .mo files shipped in the package are not identical
> > across architectures.

> I don't understand this. This would only happen if the package updates
> its *.po files during package build, which is evil and unnecessary.
> But build systems which do that would already create different *.mo
> files on each build, so whether or not you update the *.pot as well
> should make little difference.

If the .pot has not changed, a .po update will be a null merge and generate
idempotent .mo output on all builds.

If the .pot has changed, you get at minimum a change to the timestamp field
in the header; which means each .mo file will be different.

Some build systems will automatically update the .po at build time if the
.pot has changed; so this is not safe behavior on the part of
pkgbinarymangler.

The canonical example for all of this is probably apt, which ships .mo files
in a library package.

> In the ordinary case, the build sytem just builds *.mo from the source
> *.po files, and completely ignores the *.pot. Most binary packages get
> their *.mo files stripped out anyway, and for the remaining ones we
> just need to make sure that we don't put *.mo files into arch specific
> packages (either packages are arch:all anyway, or we put translations
> into an arch:all -common binary, which is quite common for GNOME
> packages).

But that implies having to change the library packages which *don't* use a
-common to work around the behavior of pkgbinarymangler, which I don't think
is what we want.