tags:

views:

225

answers:

3
+1  Q: 

macports confusion

hey i am new to the macports thing as i recently switched to the mac. as i was thinking of developing some applications in my mac i wanted all the usual gnu and opensource tools i need. but i had a small confusion. i was installing git with macports and i noticied it installed a lot of packages like Perl that i already have in my machne. so i was thinking won't there be any conflicts and how does one know which version is used. the macports one or the apple one?

+1  A: 

MacPorts installs its own dependencies in the /opt/local tree (you can change this default when you build MacPorts) because its packagers then have a known quantity to test against. In some cases there is a system package for a given dependency that will let you use the system-installed version, but that's actually pretty rare. System vs. MacPort versions are chosen according to whichever comes first on the PATH (for executables) or the linker path(s) for dynamic libraries. Use your standard development tools' options to select the appropriate libraries to link against and you should be fine.

Barry Wark
+2  A: 

MacPorts installs all of its ports into /opt/local (or whatever prefix you configured it with, but it's /opt/local by default). It installs its own copies of Perl, Python, etc., so that the MacPorts install is standardized, and to avoid conflicts (Apple-supplied versions of some programs like Perl and Python, and some libraries, often lag far behind the latest versions of those tools).

When you install MacPorts, it automatically prepends /opt/local/bin to your $PATH variable (you can change this by editing your shell configuration file), so if you call perl, etc., you'll get the MacPorts version. However, the Apple-supplied versions will still be intact and unchanged, and other programs that rely on those versions will not be affected, either.

mipadi
One caution though: if you use /opt/local/bin first in your $PATH so that the MacPorts version has precedence, be aware that there *may* be a difference between a MacPorts version and the Apple-supplied one. The one concrete and potentially critical example I've been burned by in the past is `rsync` which is pulled in as a dependency by the MacPorts `git-core` package. Unfortunately, the MacPorts rsync -aE option differs from the Apple rsync -aE: extended attributes and resource forks are silently ignored which may result in a nasty surprise later when you try to use the copied files.
Ned Deily
+2  A: 

There shouldn't be any conflicts, since MacPorts installs all of its programs under a completely separate directory hierarchy in /opt/local/.

If you have multiple versions of software installed (e.g. the default OS X Perl and MacPorts' Perl), then it depends on the order of directories in your $PATH environment variable. MacPorts typically sets itself up with its bin directories earlier in your path, so saying perl at the command line will invoke the MacPorts Perl, not the OS X Perl.

Adam Rosenfield