On Thu, Oct 30, 2003 at 06:28:43PM +0100, jfm wrote: > >... in principle what we > >should do in fink is to identify all such packages and somehow force > >them to use /usr/bin/perl instead of /sw/bin/perl when they are being > >built. This may be hard to do... > > Indeed _ a subset of those packages, besides the "580" packages : > a2ps apache2-ssl-common autoconf2.5 autoconf2.54 automake1.7 > bonobo-activation2 bow cdbkup cim cook dpkg egd enscript eterm fvwm2 > glib2-dev global gnucash gnupg groff gtk-doc gwydion-dylan help2man > http-dav-pm intltool kdepim3-common korganizer latex2html lyx makepatch > mhonarc module-info-pm mrtg mysql mysql-client net-snmp-ssl oaf > openssl097 pari-gp patchutils pgpenvelope pkg-order r-base > rtf-parser-pm test-inline-pm tetex-base texi2html w3m-ssl wml > www-search-pm xml-sax-pm xml-xpath-pm
Well, if you want to go this route, MakeMaker already has its "fixin" method to change the #! line. perl -MExtUtils::MakeMaker -e 'MM->fixin(@programs); It'll replace the #! perl with the Perl used to run fixin. Except I think fixin assumes you're always giving it a perl program and doesn't check to make sure its #!/bin/sh or something. > On Oct 29, 2003, at 11:51 PM, Michael G Schwern wrote: > > >No no, have system-perl do ln -s /usr/bin/perl /sw/bin/perl. So > >/sw/bin/perl > >exists and points to /usr/bin/perl. That way both #!/sw/bin/perl and > >#!/usr/bin/perl both work and use the Apple installed Perl. /usr isn't > >touched. > > Seems a quite plausible solution. But probably the system-perlxyz > convenience > packages should then also ensure that /sw/bin/perl points to `which > perl` for 580 > and 581, and to /usr/bin/perl5.6.1 for 561 (so all those packages would > mutually > conflict _ and one of them _ at least system-perl _ would always be > present). Well, forget `which perl`. Because 5.6.x and 5.8.x are binary compatible, you can have just system-perl56 and system-perl58. The former points /sw/bin/perl at the highest /usr/bin/perl5.6.* it can find, the latter at the highest /usr/bin/perl5.8.* it can fine. > And to realize those conflicts _ I'm not sure if it can be done with > just the system-perl > virtual package, or if one would need in addition a > system-perl-whatever convenience > package, which writes the actual link and where the conflicts can be > written explicitly, > plus then an ('essential') some_perl package, depending on at least one > of the above, > to ensure that the symlink always exists... Have a virtual package. Also have system-perl56 and 58 "provide" their version of perl (fink is using the provide flag, right?) and system-perl just grabs the one available. Choosing the right one is simple. The 10.2 tree has system-perl56, the 10.3 has system-perl58. Put a "system-perl" virtual package in both trees. The 10.2 version has a lower version number and depende on system-perl56. The 10.3 version has a higher version number and depends on system-perl58. So when someone upgrades from 10.2 to 10.3 their system-perl gets upgraded, too. Does that cover all the bases? -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ the chair. it wants to die. oh no! she sees me! she attacks! ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel