[pkg-fetchmail-maint] FYI: regarding .gmo files

[Matthias Andree]

On Mon, 09 Jan 2006, Héctor García wrote:

> There is another problem. 
> If I update any .po file, and include my update as a patch until the
> update is released by a new upstream version, package building in debian
> will fail if I call update-gmo and the .gmo file existed on the
> orig.tar.gz file.

.po corrections are to be sent to the translation project or to the
translation team. They will check the change and forward it to me, or,
more precisely, the fetchmail-devel list.

And that's the only way which I am going to accept changes, how would I
know a change isn't changing the meaning or tone in an improper way?

Besides that, changing .po files contradicts stability policies,
because users might have grep scripts tuned to parse the localized
messages, so .po files should only change for new versions, and not be
patched.

> To avoid this (missing updates on .po files and/or breakage of package
> build) the best solution is to not include the .gmo as part of upstream
> release but create them on build time.

The package build doesn't break because of .gmo files.

I am also shipping the rcfile_?.[ch], configure, config.* and many other
files and scripts although they are generated, because end users may not
have flex at all, or insufficient yacc, or whatever, and we want an easy
to install upstream package with as few dependencies as reasonable.

> I don't know your reasons to release the .gmo files but is not the usual
> thing to do. The release of binary files that can (and really should) be
> build from the sources has no much sense.

I am shipping the .gmo files because that is what gettext's makefile
does by default, with no switches to override this, and so that users
need not install the gettext-devel package, gettext-runtime will
suffice.

If you maintain that .GMO files shouldn't be shipped, please take this
up with the gettext maintainers and ask them to unlist GMOFILES from
their DISTFILES.

-- 
Matthias Andree