Re: Bug#400453: Makefile misses to clean .gmo-files in the clean target, so they get never be updated after updating an .po file (fwd)

[Daniel Leidert]

Am Dienstag, den 28.11.2006, 13:14 +0100 schrieb Daniel Leidert:
> Am Montag, den 27.11.2006, 20:08 +0100 schrieb Bruno Haible:
> 
> [..]
> > The *.gmo files are required when a maintainer does a distribution.
> > Therefore see documentation section "Release Management". It documents
> > a Makefile target 'update-po'.
> 
> I would really like to know, where a section "Release Management" can be
> found. I cannot find it in the gettext-doc package nor in the online
> documentation
> (http://www.gnu.org/software/gettext/manual/html_mono/gettext.html), nor
> the FAQ nor the CVS source.

Argh. Found it in the info pages (sorry, I'm busy and made a typo in the
grep). But it doesn't document this behaviour.

But there are also some practical problems resulting from this behaviour
change (as far as I can see):

- package distributors now always must patch the .po file _and_ update
the.gmo file (old: they only had to update the .po file in many
(probably most?) cases) to fix i18n bugs

- for at least Debian packages that means: package maintainers always
_must_ apply the resulting changes (from a i18n bug-fix) to .gmo via
patch system or dpkg-source will definitely fail with "unrepresentable
changes to source", because source ships binary files (.gmo) that may
not be altered directly - so adding update-gmo to any target in
debian/rules will make dpkg-source fail at least at the second run (if
run twice) - and because patching .po isn't longer enough, the above
step is always necessary

These issues will massively raise up as wider gettext >= 0.15 is used.

So IMHO this change _must_ be documented. @Santiago: At least in the
Debian package, I guess.

I'm really not happy with this new behaviour. Please Bruno, consider to
allow using the old behaviour. If necessary I will try to write the
patches myself if you tell me, where you would add such a switch in the
gettext macros/files.

Regards, Daniel