Although we nominally support having multiple versions of perl installed, it seems we actually don't do a very good job of it...
A couple weeks ago, I mentioned two problems that will cause multiple versions of the same module (e.g. p5.12-foo and p5.14-foo) to conflict: - they install manpages into the same location - if they install binaries, they'll all try to install into $prefix/bin [http://lists.macosforge.org/pipermail/macports-dev/2012-January/017460.html] I took a look into what it would take to fix this, but I think even if we did we've got more problems lurking. It'd take a pretty significant effort to solve them and I'm not sure it's worth it. If perl installations are supposed to be independent, then any port that depends on perl should depend on a specific version of perl5 and its modules. It shouldn't matter which variant of the perl5 metaport is installed. If something uses /opt/local/bin/perl (rather than `perl5.12`) it can't rely on that being any particular version of perl or having specific modules installed. Python has the same issue, but we've gotten pretty good over the years at making sure that ports invoke `python2.7` instead of `python`. Not so much with perl -- looking through my installed ports, I see a bunch of references to /opt/local/bin/perl, and I'm guessing at least some of them wouldn't work right with a non-default perl5 version. Sure, we could fix these ports, but I'm wondering if it's worth the effort. I'm wondering if we wouldn't be better off supporting a single version of perl5 (presumably 5.14 these days) and eliminating the p5.x-* subports. It would simplify a lot of things, and the benefits of supporting multiple simulataneous perl versions seem pretty marginal to me (but maybe I'm missing something?) Dan -- Dan R. K. Ports MIT CSAIL http://drkp.net/ _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
