intltool.m4 should use --no-translations only if >=intltool-0.50.0 is detected

[Alexandre Rostovtsev]

intltool.m4 from intltool-0.50.0 uses $(INTLTOOL_MERGE) -x -u --no-translations in INTLTOOL_XML_NOMERGE_RULE.

However, earlier versions of intltool do not support --no-translations. As a result, if a source tarball was generated on a system with intltool-0.50.0 and a user attempts to build it on a system with intltool-0.48.0, the build will fail (e.g. as reported in https://bugs.gentoo.org/show_bug.cgi?id=394445):

LC_ALL=C /usr/bin/intltool-merge -x -u --no-translations
[...]
Unknown option: no-translations
Undefined subroutine &main::error called at /usr/bin/intltool-merge line 73.
make[2]: *** [...] Error 255

A simple solution would be to use --no-translations only if INTLTOOL_APPLIED_VERSION_AS_INT >= 5000.

[Alexandre Rostovtsev (tetromino)]

Created attachment 295593
intltool-0.50.0--no-translations-version.patch

intltool.m4 from intltool-0.50.0 uses $(INTLTOOL_MERGE) -x -u --no-translations in INTLTOOL_XML_NOMERGE_RULE.

However, earlier versions of intltool do not support --no-translations. As a result, if a source tarball was generated on a system with intltool-0.50.0 and a user attempts to build it on a system with intltool-0.48.0, the build will fail (e.g. as reported in bug #394445):

LC_ALL=C /usr/bin/intltool-merge -x -u --no-translations
[...]
Unknown option: no-translations
Undefined subroutine &main::error called at /usr/bin/intltool-merge line 73.
make[2]: *** [...] Error 255

A patch to detect intltool version at configure time and use --no-translations only if version 0.50.0 is attached; I have submitted it upstream to at https://bugs.launchpad.net/intltool/+bug/903340.

Ack/nack for Gentoo in the meantime?

This bug makes it rather inconvenient to use a Gentoo ~arch system to generate source tarballs for public consumption :)

[Rafał Mużyło (galtgendo)]

Something smells fishy here: since when *forward* compatibility became a requirement for tools like intltool ?

I would wait for upstream reaction - if they see this as a reasonable change, OK, otherwise, I don't really see the point.

I'm not saying it's completely unreasonable, but it seems like fixing something, that ain't broken - there was a purpose for the change: https://bugs.launchpad.net/intltool/+bug/398576.

[Alexandre Rostovtsev (tetromino)]

(In reply to comment #1)
> Something smells fishy here: since when *forward* compatibility became a
> requirement for tools like intltool ?

Because intltool.m4 is copied into configure scripts, and those configure scripts will be run on systems with a different version of intltool utilities installed.

> I don't really see the point.

Consider the following scenario:

You are the author of a typical gnome package.
In your package's configure.ac, you have IT_PROG_INTLTOOL(0.30).
You upgrade to intltool-0.50.0 on your development machine.
You release a new version of your package and generate a release tarball (./autogen.sh; ./confugure; make; make test; make dist-xz).
Your autogen.sh calls gnome-autogen.sh, which calls intltoolize and autoreconf, and so your package's configure script is re-generated using intltool-0.50's new intltool.m4.
All tests pass, configure output says "checking for intltool >= 0.30... 0.50.0 found", so you assume that everything is fine, and that anyone with >=intltool-0.30 will be able to build your package.
You upload the tarball to ftp.
A user who has intltool-0.41 installed downloads the tarball.
The user runs configure; configure output says "checking for intltool >= 0.30... 0.41.0 found", so the user assumes that everything is fine and he has all dependencies installed.
The user runs make, and the build fails due to a --no-translations argument that his version of intltool-merge does not support.
The user is confused, assumes your package's build system is broken, and writes angry bug reports.

> I'm not saying it's completely unreasonable, but it seems like fixing
> something, that ain't broken - there was a purpose for the change:

Please re-read the patch and intltool.m4. The patch does *not* change intltool's behavior when intltool-0.50's intltool.m4 is used with intltool-0.50's intltool-merge.

Specifically:

If some package's configure script is generated using intltool-0.50's intltool.m4 and that configure script is run on a system with intltool-0.50, then at package build time intltool-merge 0.50 is called with "-x -u --no-translations", and the build succeeds.
With my patch, the behavior is the same.

If some package's configure script is generated using intltool-0.41.1's intltool.m4 and that configure script is run on a system with intltool-0.50, then at package build time intltool-merge 0.50 is called with "-x -u /tmp", and the build succeeds.
With my patch, the behavior is the same.

If some package's configure script is generated using intltool-0.50.0's intltool.m4 and that configure script is run on a system with intltool-0.41.1, then currently, at package build time intltool-merge 0.41.1 is called with "-x -u --no-translations", and the build fails.
With my patch, in this case intltool-merge 0.41.1 is called with "-x -u /tmp" (i.e. the same as it would have been if configure were generated using intltool-0.41.1's intltool.m4), and the build succeeds.

[Rafał Mużyło (galtgendo)]

(In reply to comment #2)
>(In reply to comment #1)
>> Something smells fishy here: since when *forward* compatibility became a
>> requirement for tools like intltool ?
>>
> Because intltool.m4 is copied into configure scripts, and those configure
> scripts will be run on systems with a different version of intltool utilities
> installed.
>
I'm well aware of this part, but I would consider this at most a packaging issue, where upstream has failed to notice the need to bump the required version in configure.ac.

Though I'm not saying upstream already considered and rejected this as a problem, just that I would have mixed feelings about it. Then again, even libtool has issues, if macro and script don't match.

[Alexandre Rostovtsev (tetromino)]

(In reply to comment #3)
> I'm well aware of this part, but I would consider this at most a packaging
> issue, where upstream has failed to notice the need to bump the required
> version in configure.ac.

Of course it's a packaging issue. The set of Gentoo users affected by this bug are those who are doing their own software development and packaging on their Gentoo machines. And such people will "fail to notice the need to bump the required version" because intltool-0.50.0 gives them absolutely no hint that they need to do so; the incompatibility is not documented, and the IT_PROG_INTLTOOL macro in intltool-0.50.0's intltool.m4 prints exactly the same output during a configure as in previous versions.

[Данило Шеган (danilo)]

Thanks for this report and proposed patch.

However, I wouldn't want to introduce the logic to watch for changes like these: if project maintainer is using features implemented only in intltool 0.50 (eg. the aforementioned rule requires such an update), I fully expect them to ask for users to install that version of intltool scripts on their systems. Fixing this problem was important for more than one reason, and keeping the old behaviour in for those without the required intltool version is suboptimal at best and a security risk at worst.

I am happy to hear about any suggestions on how to better document this in the future and make it an expected change, if that's ever possible. A jump from 0.4* to 0.50 was done to indicate that we're talking about significant set of changes. Also, one needs not repeat that intltool is poorly documented: it's something we'd love to get some help with.

Basically, would just adding something like the following to the release notes have helped prevent the issue:

"Use of INTLTOOL_XML_NOMERGE_RULE and intltool 0.50 by maintainers will require every user of the software to have intltool 0.50 or later installed when building the package."

If you've got something else on your mind, please let me know.

[Alexandre Rostovtsev (tetromino)]

> I am happy to hear about any suggestions on how to better document this in the future
> and make it an expected change, if that's ever possible.

Simple solution: IT_PROG_INTLTOOL should check for >=intltool-0.50 at configure time, and fail if it's not found. If the package developer has "IT_PROG_INTLTOOL(0.30)" in his configure.ac, but configure output shows "checking for intltool >= 0.50... 0.50.0 found", then he will immediately know that he should either use an older version of the .m4 file or adjust the dependencies for his package.

> "Use of INTLTOOL_XML_NOMERGE_RULE and intltool 0.50 by maintainers will require every user
> of the software to have intltool 0.50 or later installed when building the package."

That documentation is not very useful; most developers have never heard of INTLTOOL_XML_NOMERGE_RULE, they simply rely on autoconf/automake to magically insert the right make rules when IT_PROG_INTLTOOL is called :)

[Samuli Suominen (ssuominen)]

The patch was rejected by upstream wrt:

http://bugs.launchpad.net/intltool/+bug/903340/comments/7

So we are not going to apply it either. The packages need to update their DEPEND string of intltool to >=0.50.0.

[Hib Eris (hiberis)]

I would like to strongly request to allow using intltool < 0.50 when a package is build with intltool >= 0.50.
Not allowing this would make it impossible to easily compile packages on many (older, not bleeding edge) linux distributions.

It will probably cause a lot of breakage and frustration alike.

A patch working around the security issue in
https://bugs.launchpad.net/intltool/+bug/398576
is in:

lp:~hiberis/intltool/bug-903340

Sure, it is sub optimal, but forcing everyone to upgrade to intltool 0.50 is just not going to work out.

[dobey (dobey)]

Instead of having the if/else check here, why not just always use the mktemp -d solution instead? It seems like a better fix to me as it doesn't break compatibility, as adding new arguments does.

[Hib Eris (hiberis)]

IMHO, the mktemp -d solution (or any other solution using empty dirs) is just a hack to work around missing functionality in intltool < 0.50. With intltool >= 0.50, we should use the proper solution, i.e. using the --no-translations option.

Furthermore, according to http://www.gnu.org/software/autoconf/manual/autoconf.html, mktemp is not always available on all systems. Maybe it is better to use

_it_tmp_dir=tmp.intltool.$RANDOM && mkdir _it_tmp_dir

instead of

_it_tmp_dir=`mktemp -d tmp.XXXXXXXXXX`

[Данило Шеган (danilo)]

I agree we should fix it in a way Hib proposes.

[Hib Eris (hiberis)]

My patch in lp:~hiberis/intltool/bug-903340 builds upon a much more elaborate patch reorganizing intltool.m4 to allow --disable-nls (see https://bugs.launchpad.net/intltool/+bug/904647). Would you like to review (and possibly merge) that first?

Or is that too much and should I just rewrite this patch to a stand-alone patch?

[Hib Eris (hiberis)]

ping!

What should I do?

[Jordi Mallach (jordi)]

Hi Danilo,

This issue is holding me from uploading intltool 0.5x to Debian unstable. Do you think we can see a release soon that makes it possible to build tarballs created with 0.5x using intltool 0.4x soon?

Thanks a bunch!

[Данило Шеган (danilo)]

Hib, please provide a simpler patch directly against the trunk: I'd like to do another minor release with this fix, and then we can discuss .m4 refactoring separately.

[Hib Eris (hiberis)]

Updated patch as requested in lp:~hiberis/intltool/bug-903340