Another trick that RPM uses is to build multiple packages out of a single source tree. So, here's one possible scheme that wouldn't require us to implement "local" packages or have packages that fight with each other. 1) Rename perl5.8 to p5-base. 2) Remove p5-math-bigint related files from the p5-base 3) Make p5-math-bigint build itself from the perl CORE source tree. 4) Add a +cpan variant to p5-math-bigint that builds from CPAN. 5) Create perl5.8 as an empty port that depends on perl5.8 and p5-math-bigint. Now, people get the CORE install when they install perl5.8 (as expected). If they want to upgrade (many people never do), they deactivate p5-math-bigint and activate p5-math-bigint+cpan. Default works reliably, upgrades are possible, and once you upgrade, it will track upgrades. We could also reverse the default to match Daniel's suggestion. And, no PERL5LIB mucking (which I despise) and no multiple copies installed. Just an idea. -- Sal smile. -------------- Salvatore Domenick Desiano Doctoral Candidate Robotics Institute Carnegie Mellon University On Mon, 26 Feb 2007, Blair Zajac wrote: o Daniel J. Luke wrote: o > On Feb 26, 2007, at 10:34 AM, Vincent Lefevre wrote: o > > Something should be done on the MacPorts side so that o > > 1. the user isn't confused, o > o > The least surprising thing (in my opinion) is to continue to have the o > macports perl module experience match every other platform. o o I disagree, as different builds provide different module experiences. More o below. o o > o > > 2. he knows what to do to load the module provided by a port. o > o > I don't feel it's necessary to add tutorials for every port we have in the o > tree, but I wouldn't be opposed to someone writing something up. o > o > > There should be at least some information in the long description. o o If MacPorts provides a newer version of a module than the base Perl, then Perl o should pick that one up by default. I don't like the few modules we have that o clobber files from other ports, as this is just messy. o o Debian and Ubuntu can have local modules in front of the base modules: o o $ perl -V o .... o .... o Characteristics of this binary (from libperl): o Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES o PERL_IMPLICIT_CONTEXT o Locally applied patches: o SPRINTF0 - fixes for sprintf formatting issues - CVE-2005-3962 o Built under linux o Compiled at Dec 16 2005 07:48:39 o @INC: o /etc/perl o /usr/local/lib/perl/5.8.7 o /usr/local/share/perl/5.8.7 o /usr/lib/perl5 o /usr/share/perl5 o /usr/lib/perl/5.8 o /usr/share/perl/5.8 o /usr/local/lib/site_perl o . o o and Fink sets PERL5LIB to put /sw before the system's perl modules (since Fink o by default uses /usr/bin/perl and not /sw/bin/perl). o o I don't think too many people pay attention to @INC until they need it, or o they wonder why their newer module is not being picked up. o o So I vote to have out Perl have it's @INC reordered to have site_perl and o vendor_perl first. I don't think making this change will break many things, o will it? o o Regards, o Blair o o -- o Blair Zajac, Ph.D. o CTO, OrcaWare Technologies o <blair@orcaware.com> o Subversion training, consulting and support o http://www.orcaware.com/svn/ o _______________________________________________ o macports-dev mailing list o macports-dev@lists.macosforge.org o http://lists.macosforge.org/mailman/listinfo/macports-dev o o