Broken perl configuration

Derek Lamb derek at boulder.swri.edu
Thu Feb 21 14:57:55 PST 2013


Sorry for replying out-of-thread; I just got myself subscribed.  Some comments:

> Why would people care whether they have /opt/local/bin or /opt/local/libexec/perl5.12/sitebin or /my/nonstandard/macports/prefix/bin in their $PATH?

Maybe they don't care what their $PATH looks like, but I don't think that's the right issue.  The fact is that $PREFIX/libexec is not in the standard MacPorts user's $PATH, and I don't think there's a mechanism in place to adjust those $PATH entries in order to favor, say, $PREFIX/libexec/perl5.14.2/sitebin over perl5.14.1/sitebin whenever Perl5 gets a version bump.  Or if there is, it's not getting done.

> What is the suggested way to install perl scripts under Macports
> Using macports ;-)
> ... in general MacPorts (or any package management system) works best when you 'buy in' and just use it for all your install management. 
> It might make sense to set vendorbin like we're doing, but leave sitebin alone (allowing people who install outside of macports to shoot themselves in the foot)


True, but in addition to what Bruce mentioned, the p5-* Macports namespace does not cover all of CPAN (I'm not arguing that it should).  Nor is it constantly updated.  Witness p5-devel-cover @0.820.0 and all the updates that have taken place since then (http://backpan.perl.org/authors/id/P/PJ/PJCJ/).  I haven't tried to install p5-devel-cover from MacPorts, so I don't know where it puts its executables, but it is probably into libexec.  Which means that if someone installs p5-devel-cover and then tries to run 'cover', they will get a 'command not found'.  But I would be very interested if I were wrong on that.

I understand that by installing CPAN modules into the macports filespace, macports is not aware of those modules.  So every time MacPorts updates my Perl I go back to CPAN to update.  The alternative is telling CPAN to install to ~/local/perl5 or wherever.  But I think (but have not tested) that the same problem will crop up when say 5.12 gets deactiviated and suddenly there is nothing in my personal 5.14 site_perl.  So it's a horse apiece.

> Can `perl -V` be parsed to find out where things will be for a given perl? Perhaps adding a parsing of this to your $PATH will help avoid manually typing fullpaths and be a one-time tweak of the $PATH.

Sort of.  e.g.,
perl -MConfig -wE 'say "Perl module executable install location is " . ($Config::Config{sitebin}=~/libexec/ ? "not ok" : "ok") ;'

vs. the same thing but with /usr/bin/perl

It is possible to override all this libexec stuff with

perl Makefile.PL INSTALLSITEBIN=/opt/local/bin INSTALLSITESCRIPT=/opt/local/bin

and just trust (hope?) that the version being installed should be overwriting the old version.  Which is effectively what the old behavior of MacPorts Perl was.

cheers,
Derek


More information about the macports-users mailing list