Broken perl configuration

[Bruce Miller]

On 02/21/2013 11:46 AM, Daniel J. Luke wrote:
> On Feb 21, 2013, at 11:37 AM, Bruce Miller <bruce.miller at nist.gov> wrote:
>> 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.
>
> ... and those people tend to not ever use the terminal ... ;-)
>
> If you're going to use the command line, you probably need to know (at least a little) about $PATH.

Jumping in the deep end! :>

>>>> 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?
>
> you can, I guess, but I don't know if you'll get any action on it.
>
> 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).

I don't know if its really "outside" of macports;
isn't the /opt/local/bin basically only for macports?
[I vaguely recall that's not in the path on a stock mac,
and needed to be added to run anything from macports]

>>> 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.
>
> because there's a bug somewhere, or just because they can't be bothered to use the absolute path or set $PATH?

Well, firstly after a long email cycle of
   "It don't run"
and
   "I don't see any errors",
we gradually discover that it DID install successfully
just somewhere odd.

OK, now I know that it will go somewhere odd,
so I can save that step in the future.

But I still have to tell them to scan the logs to figure
out where it went _this_ time!

And probably also to suggest that they never run
   port update
(or whatever it is)
because everything will break?

>>> 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...?
>
> Your definition of 'work' is different from mine. I'm not saying that, but I don't think that having scripts/binaries installed into a place that isn't in $PATH means that something is broken.

So you do think that people should modify their PATH
everytime they install or update software?

How would a script installed via a portfile
handle this?  Is Macports also installing
a symlink from a standard place to the version
specific place? (and if so how is that different
from the normal non-versioned collision).
Or does it have some sort of alternatives management
going on? (as was mentioned in another response)

>>>> 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?
>
> Nope, but in general MacPorts (or any package management system) works best when you 'buy in' and just use it for all your install management.

Completely agree with you.
Although it's really only bad (at least in the linux world)
when you try to run manually installed software alongside
managed versions of the same software.

Of course, when I have a nice fresh system install,
I can only hold my breath so long until I have to hold
my nose and install _something_ from source, or CPAN or...

bruce

> --
> 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.          |
> +========================================================+
>
>
>