6

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!

7

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.

  • 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
  • 3
    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. – raimue Sep 13 '10 at 14:36
  • 1
    It's impossible to ignore /usr and /usr/local. These search paths are hardcoded in the compiler. – raimue 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
  • 4
    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. – raimue Dec 29 '10 at 16:54
1

It's true, mixing package managers can cause headaches. But, I use both Homebrew and MacPorts and it works because I have a small amount of packages in Homebrew. The only things that I have are end-user programs which are not (yet) available in MacPorts. For example: gist, dashing, and sqldiff. If you keep things to a minimum in one package manager or the other, the headaches become less likely.

Really, though, the only rationale for this is when you need a package that's not available in a given package manager. Personally, I've found that MacPorts has the vast majority of programs that I need and it's much more mature than Homebrew in a myriad of ways. It's also more easy to contribute to, with less stringent rules, and a nice scripting language (Tcl, which is really as nice as Ruby). There are lots of other advantages of MacPorts over Homebrew, but I'll go ahead and end my tangent here.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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