remove p5-math-bigint port?

[Salvatore Domenick Desiano]

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 at orcaware.com>
o Subversion training, consulting and support
o http://www.orcaware.com/svn/
o _______________________________________________
o macports-dev mailing list
o macports-dev at lists.macosforge.org
o http://lists.macosforge.org/mailman/listinfo/macports-dev
o 
o