Bug#484721: No longer ships (and installs) /usr/share/intltool/*-update.in

[Sebastian Dröge]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20080616/89824731/attachment.pgp