multiple perl versions

[Dan Ports]

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/