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
signature.asc
Description: This is a digitally signed message part.
