Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I heard that some people like to use both Fink and Macports since some packages exist in one and not the other.

Recently I've had trouble building and running packages like GRASS and Digikam w/ MacPorts, and have started looking at alternatives.

Just wondering: would pkgsrc and Homebrew also coexist and function nicely with them?

I am still trying out package managers and like to explore all the possibilities before I settle on one or two.

Thanks!

share|improve this question

1 Answer 1

up vote 5 down vote accepted

Homebrew will cause problems when building software from source if it is installed in /usr/local. This is the default, which is a bad choice as this path is in the default search path of compilers and other tools. Therefore builds from other packaging software might pick up the wrong dependency, using Homebrew's version instead of their own.

Years ago, in the very beginning of the project, even MacPorts was using /usr/local. But it turned out not to cooperate with other tools as is documented in their FAQ. Unfortunately Homebrew developers didn't want to hear about prior experiences and ignored such facts...

In general, it is usually better to stick to one tool only to avoid all problems. MacPorts is doing their best to patch out any harcoded paths, e.g. to /sw which is used by Fink. So usually it will work, but having anything installed in /usr/local will definitely cause problems for it.

I don't know pkgsrc enough to say if it is really affected the same way, but my best guess is that this problem applies to it as well.

There don't seem to be any open bugs for digikam or grass in MacPorts. You should report your problems to them directly with new tickets to get assistance.

share|improve this answer
2  
The point of Homebrew is to install libraries and programs not included with OS X. MacPorts didn't like using /usr/local because MacPorts installs a lot of duplicate libraries that are already included with OS X, and didn't want to have to deal with oddities if users installed the same library in /usr/local. It also wanted to isolate its entire system from everything else. MacPorts and Homebrew have different philosophies in this regard. Saying that Homebrew is bad because it installs software into /usr/local is akin to saying don't use /usr/local at all, which is silly. –  mipadi Sep 12 '10 at 19:34
2  
Nope, in the beginning MacPorts used system provided libraries. But that was not maintainable while supporting multiple versions of OS X, so the policy was changed to rely on own libraries only. The advice not to use /usr/local if you are also using MacPorts totally makes sense. The path is in the default search path of compilers and cannot be removed. –  Raim Sep 13 '10 at 14:36
1  
It's impossible to ignore /usr and /usr/local. These search paths are hardcoded in the compiler. –  Raim Sep 21 '10 at 23:57
1  
Okay, I should rephrase that: doesn't MacPorts check its own tree first? (Otherwise, there's not really a point to duplicating libraries.) On the other hand, it's important to note that Homebrew doesn't install duplicate libraries at all; it won't even install a duplicate version of Autoconf. If a particular formula does require a newer version of a duplicate library, it will install it in "keg-only" mode, that is, it puts it in the /usr/local/Cellar instead of /usr/local/lib. Homebrew is very careful about not installing stuff that may break manual compilations. –  mipadi Oct 4 '10 at 20:10
3  
No, they cannot be overridden. You can prepend other paths, but these will always be at the end of the search path. If you don't understand this, you should realize how complex the issue is and either dive in deeper or just trust us. –  Raim Dec 29 '10 at 16:54

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.