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

[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.
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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-gnome-maintainers/attachments/20080611/b4fade38/attachment.pgp