forwarded 484721 http://bugzilla.gnome.org/show_bug.cgi?id=537352 thanks
Am Donnerstag, den 05.06.2008, 23:05 +0200 schrieb Michael Biebl: > Package: intltool > Version: 0.40.0-1 > Severity: serious > Justification: should not enter testing in this state > > Hi, > > almost any GNOME app out there has the following snippet in it's > Makefile.am: > > EXTRA_DIST = \ > intltool-extract.in \ > intltool-merge.in \ > intltool-update.in > > The expectation is, that intltoolize copies these files (or symlinks them) > and > they are included in the tarball. > > With the latest upgrade, this not only breaks VCS checkouts, which now > have dangling symlinks, it also makes the upgrade path unnecessary > painful, as the Makefile.am can not be changed withouth bumping the > intltool requirement to 0.40.0, which means everyone has to upgrade at > once (a lot of current distributions don't ship intltool 0.40.0). > > 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. Thanks for reporting and the possible solution. I've forwarded this upstream now, let's hope they fix it for next release :) http://bugzilla.gnome.org/show_bug.cgi?id=537352
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil