add another linking level for perl5 binaries?

[Derek Lamb]

TL;DR:

Could we add a line to to perl5 portgroup file after line 174 that says
ln -s "${destroot}${prefix}/bin/${bin}" "${destroot}${prefix}/bin/${bin}${perl5.link_binaries_suffix}"
?

Detail:

Last month there was a conversation on this list (see "Broken Perl Configuration" around 2013-02-23) about how MacPorts handles Perl module executables (i.e., an executable script installed by a module, not the core binaries like the interpreter, etc).  This came up because various users (me included) would use CPAN to install Perl modules into /opt/local/lib/perl5.  A recent change in the perl5 port configuration sets the INSTALLSITEBIN to /opt/local/libexec and not /opt/local/bin, so the result was that a user would install their own module outside of MacPorts, the module-specific executable would be put into libexec, and it would be hard to find (at least not in their path).  The consensus was "don't install outside software into the MacPorts tree."

Today I took that to heart and deleted everything in /opt/local/lib/perl5/site_perl/.... (not touching the base Perl or the vendor_perl directories), and then installed p5-devel-cover.  That provides a binary "cover".  But there is no "cover" in my path, though I knew to look in /opt/local/libexec/perl5/ and there it was.  Then I found /opt/local/bin/cover-5.14, which is a symlink to it.  So I'm mostly happy.

But I'm wondering if we could add a link from /opt/local/bin/cover -> /opt/local/bin/cover-5.14.  Then the binary I was expecting would be in my $PATH.  The line at the top of the message I think would do the trick, maybe with a -F or -f thrown in there.  Then /opt/local/bin/cover --> /opt/local/bin/cover-5.14 --> /opt/local/libexec/perl5.14/cover.  And I think everything would be happy.  But this is my first time playing with TCL or with port[group] files so I may be wrong.

Another reason I ask is because the p5-pdl is terribly outdated, and I was thinking of either putting in to be a maintainer or submitting a patch.  As a PDL developer, having users install the package and then have no 'perldl' or 'pdl' or 'pdldoc' in their $PATH is a bit of a non-starter.

thanks,
Derek