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. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/978724 Title: pkgbinarymangler: Should build a tarball for pot import even when translations are not stripped To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-translations/+bug/978724/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
