| Summary: | dev-util/intltool-0.50.0: intltool.m4 incompatible with earlier intltool versions due to --no-translations argument | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexandre Rostovtsev (RETIRED) <tetromino> |
| Component: | [OLD] Development | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugs.launchpad.net/intltool/+bug/903340 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | intltool-0.50.0--no-translations-version.patch | ||
|
Description
Alexandre Rostovtsev (RETIRED)
2011-12-12 19:41:57 UTC
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. (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. (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. (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. 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. intltool 0.50.2 =============== intltool 0.50.2 is another minor release improving backwards compatibility. Only one bug is fixed in this release: * Use --no-translations only if intltool >= 0.50 is available (#903340). Patch contributed by Hib Eris (https://launchpad.net/~hiberis). |