Daniel Macks wrote:
On Tue, Jan 31, 2006 at 03:52:49PM -0600, Robert T Wyatt wrote:
Perhaps gimp2 in 10.3-unstable needs to depend on xml-parser-pm560:
checking for perl... /sw/bin/perl
checking for XML::Parser... configure: error: XML::Parser perl module is
required for intltool
### execution of /var/tmp/tmp.2.KN5Hlo failed, exit code 1
Failed: phase compiling: gimp2-2.0.6-1 failed
[...]
xml-parser-pm560 2.31-6
xml-parser-pm580 2.34-14
i xml-parser-pm581 2.34-14
xml-parser-pm584 2.34-14
i xml-parser-pm586 2.34-14
Installing xml-parser-pm560 allowed allowed it to pass the check.
That is a standard configure test that finds some things that intltool
needs and gimp2:BuildDepends:intltool. It looks for "first 'perl' in
PATH", and then for XML::Parser for that perl. That's pretty difficult
to enforce by dependencies, since you could have an arbitrary perl
version installed in /sw/bin/perl.
The best we can do is have intltool depend on the XML::Parser
corresponding to the perl version that is /usr/bin/perl on each OS X.
Really, that's all that is *ever* needed I think, since intltool
hardcodes itself to use /usr/bin/perl at all times.
So we have a test that seems bugged. One can force the test to use
/usr/bin/perl by setting PERL=/usr/bin/perl. We've contemplated adding
that to the intltool package, but never got around to examining what
other effects such environmental pollution might have. Same goes for
sticking that in the CompileScript of all packages that use intltool.
Which brings us back to your situation: having a test that breaks when
the user installs /sw/bin/perl (any of the perlXXX packages). And the
workable solution is to remove that perlXXX package or install the
xml-parser-pmXXX package that corresponds to it. I.e., we should
update FAQ6.20.
dan
Thanks much for the explanation Dan! I'm going to repeat what you said
to see if I got it right.
I passed this test by installing the xml-parser-pmXXX matching my
/sw/bin/perl, however what really needed to be installed is the parser
matching /usr/bin/perl (which I happened to have). The test of the
latter was not reached because the configure test checks for the parser
matching the first perl in my PATH which will always be whatever I have
in /sw/bin.
So if I don't have a fink-installed perl (and assuming I don't have some
other user-installed perl in my PATH before /usr/bin) the test will work
as intended, but otherwise it is inconclusive since it may or may not
pass for the right or wrong reason. (Which is another way of saying that
the current test needs an additional test to see if the conditions are
right.)
If I followed correctly, one could trick the test and not have the right
parser for their built-in perl but still pass by having the correct
parser for the manually-installed perl, in which case intltool will
still fail further down the road.
Which is why the best solution is to have intltool depend on XML::Parser
corresponding the /usr/bin/perl and this condition, when satisfied,
would obviate the need for the configure test that couldn't.
Thanks,
Robert
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Fink-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/fink-users
