I don't know enough background to know if the suggested fix is the right one, but I can confirm that this is a problem, and IMO a critical one: I'm already getting end users complaining that can't build Transmission tarballs because the older implementation of IT_PROG_INTLTOOL uses these .in files.

A tarball disted with intltool <= 0.37.1 uses these .in files. A tarball disted with 0.40.0 does not. If you disted with 0.40.0 and thus ship a tarball not including these files, all that is required is that intltool is installed on the system where the package is being built. Even if intltool 0.37.1 is installed on the end user system, the package will still build, unless you specified that 0.40.0 is required in the IT_PROG_INTLTOOL call in your configure.{in,ac} file.

I am not sure what problem your users are saying they have, but I can't tell you one way or the other what the solution is if I don't know what's happening. Complaints without data aren't very helpful at determining the problems.

If you can provide more data, then perhaps I could tell you what the problem is which your users are claiming to experience. Perhaps a bug report against Transmission that you could point to?

(In reply to comment #1)
> I don't know enough background to know if the suggested fix is the right one,
> but I can confirm that this is a problem, and IMO a critical one: I'm already
> getting end users complaining that can't build Transmission tarballs because
> the older implementation of IT_PROG_INTLTOOL uses these .in files.
> 

(In reply to comment #0)
> Hi,
> since version 0.40.x intltool no longer ships the
> /usr/share/intltool/*-update.in files but instead requires tarballs generated
> with intltool 0.40.x to depend on /usr/share/intltool/*-update which is a good
> decision IMHO.

It actually just requires intltool to be installe on the system where the package is being built. The only thing remaining in /usr/share/intltool is the Makefile.in.in which does need to be copied into the source tree for disting.

> Unfortunately this breaks almost every piece of software using intltool for two
> reasons:

> a) All projects had to use
> 
> EXTRA_DIST = \
>         intltool-extract.in \
>         intltool-merge.in \
>         intltool-update.in
> 
> As those files are not copied into the source directory anymore this part has
> to be removed. But after it's removal it's impossible to use with older
> intltool versions so every project needs all developers switched to the new
> intltool at the same time to keep everything working.

It is not impossible to use with older intltool versions. In fact, if you dist with 0.40.0, you can still build with 0.37.1 installed on the system, unless you explicitly specify 0.40.0 as a requirment when calling IT_PROG_INTLTOOL. You won't be able to dist with 0.37.1 of course, because the files won't be disted any longer if you remove them from EXTRA_DIST.

> b) Before the default mode was to symlink these files into the source
> directory. Every CVS/SVN/whatever checkout has dangling symlinks because of
> this now which is also rather unfortunate.

Generated files should not be stored in source control. There could be "dangling" files or symlinks if you don't clean your tree regularly before updating build tools yes, but this is true of any build tool, not specifically intltool. I could perhaps add a warning to remove the files/symlinks, similar to how aclocal complains about acinclude.m4 if it still exists.

> A solution would be (quoting
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=484721 ):
> 
> > My recommendation would be, to put the /usr/share/intltool/*-update.in
> > files back into intltool.
> > If the requested intltool version (e.g. via IT_PROG_INTLTOOL) is <
> > 0.40, intltool should behave backwards compatible and copy/symlink the
> > intltool-*.in files as before.
> > 
> > This allows all distros out there to smoothly upgrade to intltool >=
> > 0.40 and then upstream can safely bump the intltool requirement to >=
> > 0.40. In this mode, intltool would not copy the *.in files anymore and
> > the EXTRA_DIST bits would have to be removed from the Makefile.amS.
> 
> 
> I.e. having the old behaviour as default unless explicitely requesting the new
> version.

This is not a solution. The solution is to require the new version. I will not default to the old behavior. A number of developers had been requesting that intltool not install itself into the tarballs for some time. This release implements that, and I see no point in copying files around that will just go unused.

Also, it would be quite nice if debian could get rid of the intltool-debian hack they have. Why does this even exist?

(In reply to comment #3)
> (In reply to comment #0)
> > Unfortunately this breaks almost every piece of software using intltool for two
> > reasons:
> 
> > a) All projects had to use
> > 
> > EXTRA_DIST = \
> >         intltool-extract.in \
> >         intltool-merge.in \
> >         intltool-update.in
> > 
> > As those files are not copied into the source directory anymore this part has
> > to be removed. But after it's removal it's impossible to use with older
> > intltool versions so every project needs all developers switched to the new
> > intltool at the same time to keep everything working.
> 
> It is not impossible to use with older intltool versions. In fact, if you dist
> with 0.40.0, you can still build with 0.37.1 installed on the system, unless
> you explicitly specify 0.40.0 as a requirment when calling IT_PROG_INTLTOOL.
> You won't be able to dist with 0.37.1 of course, because the files won't be
> disted any longer if you remove them from EXTRA_DIST.

Agreed, it's really only a problem for those who create the tarballs. Everybody else can intltoolize with whatever version they want and things will continue to work.

> > b) Before the default mode was to symlink these files into the source
> > directory. Every CVS/SVN/whatever checkout has dangling symlinks because of
> > this now which is also rather unfortunate.
> 
> Generated files should not be stored in source control. There could be
> "dangling" files or symlinks if you don't clean your tree regularly before
> updating build tools yes, but this is true of any build tool, not specifically
> intltool. I could perhaps add a warning to remove the files/symlinks, similar
> to how aclocal complains about acinclude.m4 if it still exists.

That's a problem for people who have n+1 different CVS/SVN/whatever checkouts on their disk and update to the new intltool. But I agree that this is not a too bad problem.

> Also, it would be quite nice if debian could get rid of the intltool-debian
> hack they have. Why does this even exist?

That's really a good question. I don't know why it exists and it seems to be more or less unmaintained anyway and it's just used by lintian and po-debconf for some reason.

README.Debian says:

> Intltool is a collection of scripts written by the GNOME project to
> help its localization.  It supports many file formats, and I submit
> patches for our rfc822 format files.  They are incorporated upstream,
> but this support is still not finalized.  As debconf l10n is now
> performed via intltool scripts, the intltool-debian package is
> intended to quickly fix bugs when found, without breaking the
> GNOME part.

Is the rfc822 support finalized now? I guess so, intltool-debian should probably go away now.

(In reply to comment #4)
> Is the rfc822 support finalized now? I guess so, intltool-debian should
> probably go away now.

I don't know, as I don't know what debian needs that we presumably don't have.
It would be nice if whoever created that package could file the necessary bugs/patches here so that we can determine the correct course of action, though.

(In reply to comment #4)
> Agreed, it's really only a problem for those who create the tarballs. Everybody
> else can intltoolize with whatever version they want and things will continue
> to work.

> That's a problem for people who have n+1 different CVS/SVN/whatever checkouts
> on their disk and update to the new intltool. But I agree that this is not a
> too bad problem.

Does this mean that we can close this bug, and likewise, the downstream debian bug, and just go on with life? I don't see a true critical issue here, and your statements seem to agree with that.

Yeah I guess we can close this bug. The original bug reporter doesn't agree though

(In reply to comment #7)
> Yeah I guess we can close this bug. The original bug reporter doesn't agree
> though

Hrmm. I think the downstream reporter has his assumptions a little misplaced. What does he do when developing against shared libraries that aren't available on elsewhere? Do they not have to build those libraries there as well? If you're going to develop against the latest version, then you should require the latest version, and people on platforms that do not have packages of that version, can build it themselves. That is how development works, when you have so many different distributions. You can't ever assume that everyone who will ever contribute to the project will have the same environment as you. What about Debian Stable vs. Unstable users? What about older versions of Fedora, SUSE, or whatever other distro? At some point you just have to install the new software.

FWIW, this is a huge annoyance for building distro packages, because you have to add an intltool BR to every single package. Injecting a perl dependency into configure was not good enough for intltool, it seems. You had to go the whole way and inject a dependency on intltool itself.

Well done...

I don't know what your issue with PERL is, but intltool has always dependend on it. Whether or not your packages correctly had a build requirement for it or not, is a packaging issue on your end. The change was made due to the clear majority want of removing intltool from being a part of each individual package, and making it a build time dependency.

Please don't post to closed bugs with only your poor sarcasm. Lots of things are annoying to do, but we don't all post in your bugs with "switching to gvfs/gio is annoying when we already use gnome-vfs. way to go." This bug was closed over a month ago. If you don't have anything constructive to provide, please don't post in the bugs. It is a waste of time and bandwidth for everyone involved.

(In reply to comment #9)
> FWIW, this is a huge annoyance for building distro packages, because you have
> to add an intltool BR to every single package. Injecting a perl dependency into
> configure was not good enough for intltool, it seems. You had to go the whole
> way and inject a dependency on intltool itself.
> 
> Well done...
> 

That majority only exists in your imagination.

As far as I was told, this should work:

- drop the intltool-* files from EXTRA_DIST in Makefile.am
- set the intltool requirement in configure.ac to 0.37.1
- "make dist" using intltool 0.40.0

The package should now build fine with most intltool versions currently in use.

(Note that I could be wrong...)

Wouter is correct.

And please don't go around reopening bugs because you are "annoyed" with your packaging problems. If you have TECHNICALLY VALID INFORMATION to provide to the bug, and constructive discussion, then so be it. But "I am annoyed with packaging because of this change" is not it.

You broke the build of a lot of packages and installing from tarballs when intltool isn't installed. I didn't see any advanced warnings of this change of behaviour on desktop-devel-announce, or any other mailing-lists, only people complaining (and rightfully so) after the fact.

Next time, please announce this sort of changes well in advance using the correct channels.

Rodney, the bottom line is basically that build tools can't break backwards compatibility.  The options are parallel installability (see automake-*) or new mode flags (e.g. --mode=2).

I've added a line to create empty versions of these files for backward compatibility for people who want to keep extra crap in their Makefile.am instead of just upgrading and moving on. The intltool package still remains a requirement to be installed on the system where the package is being built though, and that won't change.