Re: libgnomecanvas2-shlibs-2.20.1.1-3 and gnome-doc-utils-0.14.2-2

On Wed, Apr 22, 2009 at 09:40:13PM +0200, Peter Dyballa wrote:
> Hello!
> 
> The configure script of all other GNOME related packages finds:
> 
> 	checking for intltool >= 0.35.0... 0.40.5 found
> 	checking for intltool-update... /sw/bin/intltool-update
> 	checking for intltool-merge... /sw/bin/intltool-merge
> 	checking for intltool-extract... /sw/bin/intltool-extract
> 
> or
> 
> 	checking for intltool >= 0.40.0... 0.40.5 found
> 	checking for intltool-update... /sw/bin/intltool-update
> 	checking for intltool-merge... /sw/bin/intltool-merge
> 	checking for intltool-extract... /sw/bin/intltool-extract
> 
> but for these two it finds:
> 
> 	checking for intltool >= 0.35.0... 0.35.5 found

Some parts of intltool are included in the source tarball or added
when "autoreconf" or similar tools are run. I think this ./configure
specific test examines the files present in the build dir rather than
those present in the external intltool package itself. So gnomecanvas2
itself has intltool-0.35.5 components because that's what was present
on the system where the source dist was tarred. If the fink package
for gnomecanvas2 redid all the autotool and other dist processes with
intltool-0.40 present, it would then contain and find this newer
intltool. gnomecanvas2 itself is old upstream (they did not release a
new version in either of the most recent two gnome suite versions), so
it's not surprising that it contains old intltool because that's what
existed back then. Almost everything else in gnome is itself at a
newer version, so then come with newer intltool support files. because
that's what was current when their tarballs were rolled. Alternately,
some other packages redo the autotools as part of the build, so they
include newer intltool because that's what fink can supply.

There is some concern (though I think allayed) that because intltool
might use some files from the source dist but also some files present
from the actual intltool package and there were some substantial
changes between intltool 0.35ish and 0.40ish. That is, mixing might
cause problems (tarball with intltool-0.35 being compiled with
intltool-0.40 installed). We therefore have the new intltool as a
separate package-name, so each package can make sure the newer 0.40
doesn't break things and explicitly migrate to it (per notes in the
intltool*.info package descriptions). When (or more likely if:( every
package can build successfully with a BDep:intltool40 rather than
BDep:intltool, we can scrap the old version entirely from fink.

dan

-- 
Daniel Macks
[email protected]
http://www.netspace.org/~dmacks


------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and 
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today. 
Use priority code J9JMT32. http://p.sf.net/sfu/p