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