Messed up Perl

Michael_google gmail_Gersten keybounce at gmail.com
Mon Oct 4 13:04:05 PDT 2010


> ... your issue is that MacPorts didn't do what you want automatically.
>
> Historically, we have done three different things with PATH:
>
> 1. Nothing (my preferred solution)
>  - This results in large numbers of "I installed this with MacPorts and I can't use it" emails to the mailing list
> 2. Append to the PATH
>  - This results in large numbers of "Why isn't the MacPorts _foo_ I installed running instead of the system one" emails to the mailing list
> 3. Prepend to PATH
>  - This results in a few very angry rants from people who are confused about what is happening (and usually it seems to be people running perl who don't realize that there's a difference between /usr/bin/perl and /opt/local/bin/perl and associated modules).
>
> Prepend to PATH seems to enable behavior that most of our users expect - and it's easy enough for those who want other behavior to change their own path.
>
> If you have a better solution, I'm sure we're happy to hear it.

So it basically sounds like,

If I install X via macports, I want to use macports X and not system X.
Otherwise, I want to use system Y, and the macports programs specify
the macports Y.

So, for any program with a local version and a system version, we need
a generic_select program.

So the first question is, how does python_select work, and can we make
a generic_select?

And note that this doesn't quite address the issue of "User 1 installs
the newest perl for their use, but user 2 wants the older, system
perl". But we must have run into that with python already -- how do
python users deal with multiple users on a system wanting different
versions?
-- 
Political and economic blog of a strict constitutionalist
http://StrictConstitution.BlogSpot.com


More information about the macports-users mailing list