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!

hpy
  • 6,001
  • 20
  • 60
  • 86

2 Answers2

6

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.

raimue
  • 630
  • 3
  • 9
  • 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
  • Doesn't MacPorts set up its own search paths anyway, ignoring `/usr` and `/usr/local`? MacPorts obviously doesn't search `/usr` when looking for libraries, since it installs its own copies anyway. – mipadi Sep 17 '10 at 14:50
  • 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 04 '10 at 20:10
  • *It's impossible to ignore /usr and /usr/local* - these are defaults that are quite straightforwardly overridden with options. @mipadi is right. – Charles Stewart Nov 26 '10 at 13:04
  • 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
  • Raim: You can notify people of your responses by prefixing enough of their name with @, so, e.g., @Charles. LDFLAGS=-Z will wipe out /usr and /usr/lib from the ld defaults, although I see that you are right - some Macports packages, incomprehensibly, will put these right back in their search path: https://trac.macports.org/ticket/23400 (look at the invocation of gcc). If I cared about Macports, I'd file this as a bug, but I'll just add this to the list of reasons why I find Macports less tolerable than Homebrew and Fink. – Charles Stewart Jun 24 '11 at 10:00
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.

GDP2
  • 151
  • 1
  • 9