Bug#484721: No longer ships (and installs) /usr/share/intltool/*-update.in
Am Mittwoch, den 11.06.2008, 13:15 +0200 schrieb Michael Biebl: Sebastian Dröge wrote: severity 484721 minor thanks Am Montag, den 09.06.2008, 09:59 +0200 schrieb Sebastian Dröge: 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 Ok, so after thinking about it a bit more and after reading the upstream comments to the bug I've came to the conclusion that this bug is, if anything, just minor. a) the dangling symlinks problem is still valid, upstream thinks about adding some checks for warning about them or removing them. b) The upgrade path problem is not valid IMHO. Projects that still use 0.40 intltool can be intltoolize'd by intltool 0.40 without any problems and the building will work just fine. It's only make dist/distcheck that will fail but this is more or less only important for the people making the release. They can either downgrade their intltool or update the source for intltool 0.40. Projects that have switch to intltool =0.40 can be intltoolize'd by older intltool without problem. It will have the files copied or linked into the source tree and building, etc will work fine. make dist/distcheck will of course create tarballs that won't work as they don't include the intltool-* scripts but that's IMHO no problem as the people making the release should use the new version of intltool if the source was switched. Projects that have tarballs generated with intltool 0.40 require only intltool 0.3x for building to be installed. This is just an added build dependency and not a too new version. I agree that this problem is mostly relevant for developers. But the upgrade path is still a major issue. Why? Developers usually work from VCS checkouts, so the sources are *not* intltoolized. Now, what should one do, if one developer is working on Fedora 9 (intltool 0.37) and one on Debian unstable (intltool 0.40). I can't just remove the EXTRA_DIST bits because it would break make dist for the Fedora guy. If I don't remove the EXTRA_DIST bits, I, on Debian, can't run make distcheck anymore, which is useful, even if you are not the one preparing the final tarball. You could keep the removed EXTRA_DIST as a local change (or the Fedora guy could keep the EXTRA_DIST as a local change) and everybody is happy. I'm sure, a patch to *require* intltool 0.40 won't be accepted upstream atm, as none of the other upstream distros ships intltool 0.40, and I can't force every other developer to compile and install intltool 0.40 by hand. So I strongly disagree with Rodney in that regard. My outlined proposal is imho still the better solution for a imho major issue. As upstream absolutely doesn't agree here I don't know what to do. IMHO we should simply close this bug as it's IMHO not a too big issue and can be easily worked around for those who care. The next round of other distros will probably all contain intltool 0.40 and then someone could come and file the same bug again because Debian is still at 0.3X and things fail the way you describe. signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#484721: No longer ships (and installs) /usr/share/intltool/*-update.in
severity 484721 minor thanks Am Montag, den 09.06.2008, 09:59 +0200 schrieb Sebastian Dröge: 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 Ok, so after thinking about it a bit more and after reading the upstream comments to the bug I've came to the conclusion that this bug is, if anything, just minor. a) the dangling symlinks problem is still valid, upstream thinks about adding some checks for warning about them or removing them. b) The upgrade path problem is not valid IMHO. Projects that still use 0.40 intltool can be intltoolize'd by intltool 0.40 without any problems and the building will work just fine. It's only make dist/distcheck that will fail but this is more or less only important for the people making the release. They can either downgrade their intltool or update the source for intltool 0.40. Projects that have switch to intltool =0.40 can be intltoolize'd by older intltool without problem. It will have the files copied or linked into the source tree and building, etc will work fine. make dist/distcheck will of course create tarballs that won't work as they don't include the intltool-* scripts but that's IMHO no problem as the people making the release should use the new version of intltool if the source was switched. Projects that have tarballs generated with intltool 0.40 require only intltool 0.3x for building to be installed. This is just an added build dependency and not a too new version. If you still see any problem that justifies intltool 0.40 not going to testing please tell me :) signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Bug#484721: No longer ships (and installs) /usr/share/intltool/*-update.in
Sebastian Dröge wrote: severity 484721 minor thanks Am Montag, den 09.06.2008, 09:59 +0200 schrieb Sebastian Dröge: 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 Ok, so after thinking about it a bit more and after reading the upstream comments to the bug I've came to the conclusion that this bug is, if anything, just minor. a) the dangling symlinks problem is still valid, upstream thinks about adding some checks for warning about them or removing them. b) The upgrade path problem is not valid IMHO. Projects that still use 0.40 intltool can be intltoolize'd by intltool 0.40 without any problems and the building will work just fine. It's only make dist/distcheck that will fail but this is more or less only important for the people making the release. They can either downgrade their intltool or update the source for intltool 0.40. Projects that have switch to intltool =0.40 can be intltoolize'd by older intltool without problem. It will have the files copied or linked into the source tree and building, etc will work fine. make dist/distcheck will of course create tarballs that won't work as they don't include the intltool-* scripts but that's IMHO no problem as the people making the release should use the new version of intltool if the source was switched. Projects that have tarballs generated with intltool 0.40 require only intltool 0.3x for building to be installed. This is just an added build dependency and not a too new version. I agree that this problem is mostly relevant for developers. But the upgrade path is still a major issue. Why? Developers usually work from VCS checkouts, so the sources are *not* intltoolized. Now, what should one do, if one developer is working on Fedora 9 (intltool 0.37) and one on Debian unstable (intltool 0.40). I can't just remove the EXTRA_DIST bits because it would break make dist for the Fedora guy. If I don't remove the EXTRA_DIST bits, I, on Debian, can't run make distcheck anymore, which is useful, even if you are not the one preparing the final tarball. I'm sure, a patch to *require* intltool 0.40 won't be accepted upstream atm, as none of the other upstream distros ships intltool 0.40, and I can't force every other developer to compile and install intltool 0.40 by hand. So I strongly disagree with Rodney in that regard. My outlined proposal is imho still the better solution for a imho major issue. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#484721: No longer ships (and installs) /usr/share/intltool/*-update.in
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
Bug#484721: No longer ships (and installs) /usr/share/intltool/*-update.in
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. Cheers, Michael -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25.4 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages intltool depends on: ii automake [automaken] 1:1.10.1-3 A tool for generating GNU Standard ii automake1.7 [automaken] 1.7.9-9A tool for generating GNU Standard ii automake1.8 [automaken] 1.8.5+nogfdl-2 A tool for generating GNU Standard ii automake1.9 [automaken] 1.9.6+nogfdl-3 A tool for generating GNU Standard ii file 4.24-2 Determines file type using magic ii gettext 0.17-2 GNU Internationalization utilities ii libxml-parser-perl2.36-1.1+b1Perl module for parsing XML files ii patch 2.5.9-5Apply a diff file to an original ii perl 5.10.0-10 Larry Wall's Practical Extraction intltool recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
