It seems that the Math:BigInt module is provided by perl: prunille:~> port contents perl5.8 | grep BigInt.pm /opt/local/lib/perl5/5.8.8/Math/BigInt.pm It is version 1.77. The version provided by the p5-math-bigint port is 1.73 only. Is there a reason to keep such a port that is not up-to-date and that will never be used because perl first selects the modules distributed with the perl5 port? BTW, the latest version of Math::BigInt on CPAN is 1.79. Shouldn't perl5 be upgraded? -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Feb 24, 2007, at 7:54 AM, Vincent Lefevre wrote:
It is version 1.77. The version provided by the p5-math-bigint port is 1.73 only. Is there a reason to keep such a port that is not up-to-date and that will never be used because perl first selects the modules distributed with the perl5 port?
A module can explicitly load the non-core module.
BTW, the latest version of Math::BigInt on CPAN is 1.79.
There probably isn't a reason to have the older one in the tree (but there could be a reason to have the newer one available).
Shouldn't perl5 be upgraded?
I'm not sure what you mean, there's no perl5 port. The perl5.8 port is for the latest stable perl release 5.8.8. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-02-24 10:50:32 -0500, Daniel J. Luke wrote:
On Feb 24, 2007, at 7:54 AM, Vincent Lefevre wrote:
It is version 1.77. The version provided by the p5-math-bigint port is 1.73 only. Is there a reason to keep such a port that is not up-to-date and that will never be used because perl first selects the modules distributed with the perl5 port?
A module can explicitly load the non-core module.
But loading an explicit version isn't standard. The installation should be set up so that the latest version is loaded with "use <module>;".
BTW, the latest version of Math::BigInt on CPAN is 1.79.
There probably isn't a reason to have the older one in the tree (but there could be a reason to have the newer one available).
Currently this isn't really useful since use Math::BigInt lib => 'GMP'; loads the core module, with the default @INC. If someone installs p5-math-bigint because it is more recent than the core version, he probably wants it to be loaded instead of the core version.
Shouldn't perl5 be upgraded?
I'm not sure what you mean, there's no perl5 port. The perl5.8 port is for the latest stable perl release 5.8.8.
Yes, I meant the perl5.8 port. Wouldn't that make version 1.79 available? (Version 1.77 isn't even on CPAN any longer.) -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On Feb 24, 2007, at 5:17 PM, Vincent Lefevre wrote:
A module can explicitly load the non-core module.
But loading an explicit version isn't standard. The installation should be set up so that the latest version is loaded with "use <module>;".
BTW, the latest version of Math::BigInt on CPAN is 1.79.
There probably isn't a reason to have the older one in the tree (but there could be a reason to have the newer one available).
Currently this isn't really useful since
use Math::BigInt lib => 'GMP';
loads the core module, with the default @INC. If someone installs p5-math-bigint because it is more recent than the core version, he probably wants it to be loaded instead of the core version.
So, yes, someone who uses macports to install perl modules still needs to understand how perl module loading works (and how CORE modules are loaded in preference to user/vendor installed modules with normal @INC ordering).
Shouldn't perl5 be upgraded?
I'm not sure what you mean, there's no perl5 port. The perl5.8 port is for the latest stable perl release 5.8.8.
Yes, I meant the perl5.8 port. Wouldn't that make version 1.79 available? (Version 1.77 isn't even on CPAN any longer.)
Nope. perl5.8.8 comes with CORE modules in its distfile. The options (as I see them) are: - Leave things as they are, which is a little bit confusing, but matches 'normal' perl behavior. - Have perl ports that upgrade CORE modules overwrite files from the perl5.8 port (to mimic how people normally upgrade CORE modules). This obviously has some issues. - Change the @INC ordering to something non-standard (ie. User, Vendor, CORE instead of CORE, User, Vendor). Deal with the compatibility issues that may or may not result. - Get an upstream perl change (in @INC or something else) to make the behavior match your expectation. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-02-26 10:08:34 -0500, Daniel J. Luke wrote:
perl5.8.8 comes with CORE modules in its distfile.
The options (as I see them) are: - Leave things as they are, which is a little bit confusing, but matches 'normal' perl behavior. - Have perl ports that upgrade CORE modules overwrite files from the perl5.8 port (to mimic how people normally upgrade CORE modules). This obviously has some issues. - Change the @INC ordering to something non-standard (ie. User, Vendor, CORE instead of CORE, User, Vendor). Deal with the compatibility issues that may or may not result. - Get an upstream perl change (in @INC or something else) to make the behavior match your expectation.
Something should be done on the MacPorts side so that 1. the user isn't confused, 2. he knows what to do to load the module provided by a port. There should be at least some information in the long description. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
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.
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.
-- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
On 2007-02-26 11:01:23 -0500, 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.
Yes, but for instance, Debian doesn't provide a package for Math::BigInt. vin:~> apt-file search Math/BigInt.pm perl-modules: usr/share/perl/5.8.4/Math/BigInt.pm perl-modules: usr/share/perl/5.8.8/Math/BigInt.pm i.e. it comes from the core modules only. Now, should MacPorts provide a p5-math-bigint port or should one do like Debian, i.e. provide the core module (in the perl5.8 port) only? -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
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/
On Feb 26, 2007, at 1:16 PM, Blair Zajac wrote:
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.
What about when the module author changes the API? It's not totally unreasonable for scripts to assume that CORE modules won't have API changes (and that is probably why the default @INC ordering is the way it is). Incidentally, the 'normal' way of upgrading CORE modules is to clobber the installed one (yes, I don't like it either).
Debian and Ubuntu can have local modules in front of the base modules:
... which isn't as interesting to me as if the perl-distributed hints file has a different @INC or not (if it does, I would find it persuasive to change macports behavior, if not, then not so much).
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?
It won't break things as long as newer modules never change API or semantics. I would guess that CORE modules aren't very unstable and it probably won't be a problem, but I wouldn't want to bet on it. -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
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
On 2007-02-26 13:25:40 -0500, Daniel J. Luke wrote:
On Feb 26, 2007, at 1:16 PM, Blair Zajac wrote:
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.
What about when the module author changes the API?
There could be a rule for such ports: accept bug fixes only. I suppose that if the module author changes the API, it would clearly be announced, in particular for a core module. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
On 2007-02-26 14:28:55 -0500, Salvatore Domenick Desiano wrote:
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.
I think you meant p5-base. Debian does something like that too (perl is an almost-empty package that depends on perl-base and perl-modules). But I don't think a rename would be necessary. perl5.8 should just depend on p5-math-bigint, if I understand correctly. -- Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
o > 1) Rename perl5.8 to p5-base. o > 2) Remove p5-math-bigint related files from the p5-base o > 3) Make p5-math-bigint build itself from the perl CORE source tree. o > 4) Add a +cpan variant to p5-math-bigint that builds from CPAN. o > 5) Create perl5.8 as an empty port that depends on perl5.8 and o ^^^^^^^ o > p5-math-bigint. o o I think you meant p5-base. Debian does something like that too Correct. o But I don't think a rename would be necessary. perl5.8 should o just depend on p5-math-bigint, if I understand correctly. I think there might b ea circular dependency problem the other way -- p5-math-bigint has to depend on perl5.8, so perl5.8 can't depend on p5-math-bigint. That's where the p5-base comes in. Breaks the cycle. The other question would be how to do this without breaking everybody's ports. Maybe we wait until the next release to introduce this scheme. -- Sal smile.
participants (4)
-
Blair Zajac
-
Daniel J. Luke
-
Salvatore Domenick Desiano
-
Vincent Lefevre