Daniel J. Luke wrote:
On Feb 26, 2007, at 10:34 AM, Vincent Lefevre wrote:
Something should be done on the MacPorts side so that 1. the user isn't confused,
The least surprising thing (in my opinion) is to continue to have the macports perl module experience match every other platform.
I disagree, as different builds provide different module experiences. More below.
2. he knows what to do to load the module provided by a port.
I don't feel it's necessary to add tutorials for every port we have in the tree, but I wouldn't be opposed to someone writing something up.
There should be at least some information in the long description.
If MacPorts provides a newer version of a module than the base Perl, then Perl should pick that one up by default. I don't like the few modules we have that clobber files from other ports, as this is just messy. Debian and Ubuntu can have local modules in front of the base modules: $ perl -V .... .... Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 Built under linux Compiled at Dec 16 2005 07:48:39 @INC: /etc/perl /usr/local/lib/perl/5.8.7 /usr/local/share/perl/5.8.7 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . and Fink sets PERL5LIB to put /sw before the system's perl modules (since Fink by default uses /usr/bin/perl and not /sw/bin/perl). I don't think too many people pay attention to @INC until they need it, or they wonder why their newer module is not being picked up. So I vote to have out Perl have it's @INC reordered to have site_perl and vendor_perl first. I don't think making this change will break many things, will it? Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies <blair@orcaware.com> Subversion training, consulting and support http://www.orcaware.com/svn/