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 _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
