Le 17 mai 2005 à 09:42, Daniel Macks a écrit :
So that is always Fink's one, is not it (at least when compiling via fink)? Or is it always /usr/bin in this case?Taking this to -devel because it's a symtom of a general problem. Consider *not* replying to -gnome-core...
On fink-gnome-core, Mich?le Garoche wrote:
Compiling gimp2 after using buildfink makes it failed because of an apparently missing dependency on xml-parser-pm586:
checking for perl... /usr/bin/perl configure: error: XML::Parser perl module is required for intltool ### execution of F77=no failed, exit code 1 Failed: phase compiling: libgnomeprint2.2-2.6.2-9 failed
intltool is pretty annoying because of this. The current best-practice is for any package that needs intltool to BuildDepends:intltool, even though it doesn't actually need that package, since the intltool package in each dist has Depends on the xml-parser-pmXXX matching the perlXXX that is /usr/bin/perl in that dist.
OTOH, the AC_PROG_INTLTOOL macro really uses "first 'perl' in PATH".
As a result, if the user has a /sw/bin/perl from a perlXXY package, the intltool placeholder pkg is bogus: the dep it gives is not needed
I don't understand here, it would have thought the other way around.
and the dep that *is* needed is not specified.
?
I don't know if I understood correctly. Do you say that intltool should always search its related xml-parser-whatever in /usr/bin/ perl, no matter if the user has or not installed a Fink version or any other version of perl?
One can set INTLTOOL_PERL to a specific path in order to over-ride the PATH search, so perhaps a cleaner solution is to set that to /usr/bin/perl and then XXX in BuildDepends:xml-parser-pmXXX is not affected by perlXXY packages. Does endowing the intltool package with a RuntimeVars:INTLTOOL_PERL:/usr/bin/perl work as an improvement on our current best-practice?
Or, if I understand now better, say you have set this variable, then you install a newer version of Perl (via Fink for example). What happens next? intltool points always to /usr/bin/perl; but maybe you need /sw/bin/perl in this case? Or any installation of Perl (via Fink) reset this to /sw/bin/perl, but what happens when the user installs locally a newer version thereafter? (yes, I know I'm a bit paranoiac, nevertheless it's quite possible).
That would be better, this way it ensures that every package which needs it has it.Or are we better off scrapping that approach and just setting it in each package directly and adding the BDep for the now-more-certain xml-parser-pmXXX?
I thought about hacking the AC_PROG_INTLTOOL macro with something like `which perl` result, would it work?
Cheers, Michèle <http://micmacfr.homeunix.org>
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
