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

[Sebastian Dröge]

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 :)
   
-------------- 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/20080611/0690f501/attachment.pgp