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