On Tuesday 11 June 2013 05:55:14 Pacho Ramos wrote:
> Because of:
> https://bugs.gentoo.org/show_bug.cgi?id=432848
> 
> We discovered an old bug affecting intltool that causes prefix of
> localedir to be always hardcoded to the same location instead of
> respecting configure flags.
> 
> The patch is fixed by intltool upstream in their master branch but still
> no new version was released including it. Anyway, we now have
> dev-util/intltool-0.50.2-r1 with the bug fixed.
> 
> The problem of this issue (and most involving intltool) is that we need
> to run:
> intltoolize --copy --automake --force
> (it doesn't seem to trigger maintainer mode in all ebuilds I have tried,
> then, doesn't look to require eautoreconf to be run)
> 
> for all packages to get new and fixed ${S}/po/Makefile.in.in copied to
> the sources, otherwise bundled file is used and, then, the one unfixed.
> As it's unreliable to ping all upstreams involving intltool (they are a
> ton) and this kind of problem will likely re-appear again in the future
> (since the Makefile.in.in will be fixed in intltool upstream tarball but
> will take a lot of time to reach all affected packages) we were
> considering to run above command always at eclass level -> that way we
> would stop using bundled ${S}/po/Makefile.in.in and, then, we would
> always use the one provided by our intltool package (that should get
> fixed and updated more often).
> 
> Other possible solution would be to use ELT-PATCHES to achieve that, but
> I am still unsure about how would it work.

ELT-PATCHES is only used by elibtoolize which means it requires an explicit 
call to patch things

you're basically talking about the same type of problem that 
https://bugs.gentoo.org/220040 tried to address.  maybe we should update 
autotools.eclass to have a general patching mechanism since any EAPI based one 
is doomed to failure.  and then we rebase elibtoolize to that.
-mike