Broken perl configuration

[Bruce Miller]

On 02/21/2013 11:05 AM, Daniel J. Luke wrote:
> On Feb 21, 2013, at 10:05 AM, Bruce Miller <bruce.miller at nist.gov> wrote:
>> With MacPort's perl 5.12, the executable is installed in
>>   /opt/local/libexec/perl5.12/sitebin
>> which is *NOT* where people expect to find programs.
>> And it's NOT a directory people want to maintain in
>> their $PATH.
>
> why? 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?

People care if they have to maintain $PATH themselves,
and then they have to keep track of the versions of Perl
and whatever else they're using so that the appropriate
versions appear in the $PATH.

And, let's be frank; Macs cater (wisely, perhaps) to
a group of users who don't know about, or want to know about, $PATH.

>> This is all due to a configuration change with MacPort's perl,
>> and there's a ticket about this
>>   https://trac.macports.org/ticket/36980
>
> well, my read of that ticket is that 'libexec' isn't really the right place

So, should we file a new ticket that is more specific?

>> The reason for the configuration change
>> is to achieve the noble goal of being able
>> to install multiple versions of Perl, and
>> multiple versions of software running under
>> those Perls.
>
> yeah it's a version specific directory for things to install into (could have been ${prefix}/bin/perl5.12/ or something like that instead)
>
>> With the minor cost that
>> _nothing_ runs.
>
> not really, it all runs fine - you just have to deal with $PATH or use the full path to the script you want to run.

Well, for half my mac users it doesn't run.

>> I've tried, on the above ticket, to suggest
>> that the approach used may not be the best one;
>> or at any rate, please tell me a workaround.
>> I only got a vague answer about symlinks
>> (which doesn't really solve much).
>
> symlinks would be the 'normal' macports way to solve this (ie one would install the perl module via MacPorts, it would install the scripts into the perl-specified location that you hate, and you could optionally create symlinks in ${prefix}/bin).
>
>>   What is the suggested way to install perl scripts
>> under Macports?
>
> Using macports ;-)

Sure, although I'm sadly behind in getting an official release,
I _do_ have a portfile....

But are you seriously saying that the Perl that comes with MacPorts
shouldn't be expected to work with non-macports Makes or CPAN or...?

Even if I have the portfile adjusted, it would be nice
if people could check out a more recent version of
my software from svn.  Now I'll grant that svn
isn't for the most naive user.  But if I have to add
"Now scan through the meg of log data looking for where
the damn thing got installed _this_ time",
it starts to bet pretty inconvenient.

>> How should I modify my Makefile.PL?
>
>
> you shouldn't, you should modify your Portfile.

So the Perl really only supports MacPorts,
and shouldn't be expected for general use?

How about you configure Perl so that Portfiles will
deal with all the versioning magic and hide things where
you want.  But a plain old Makefile.PL will just do the
Right Thing.
Would that be workable?

No, I guess I can answer that myself; you've got the
executables being installed in two different places,
potentially both on the $PATH, which is what I'm trying
to avoid.  So, nevermind that.

> As an aside, I personally don't feel that the benefits of having multiple perl versions available is worth it - I think we would be better served by just pushing the current stable perl...

I can't disagree.

> --
> Daniel J. Luke
> +========================================================+
> | *---------------- dluke at geeklair.net ----------------* |
> | *-------------- http://www.geeklair.net -------------* |
> +========================================================+
> |   Opinions expressed are mine and do not necessarily   |
> |          reflect the opinions of my employer.          |
> +========================================================+
>
>
>