gnome - How can we "persuade" fink, port, & brew to coexist in parallel on OSX Mavericks?

06
2014-04
  • Bill McCloskey

    We like to use brew, but it doesn't have a lot of gnome toolset formulae, and we can install a gnome-terminal very quickly with FinkCommander. We've built various parts of gnome from scratch, but creating a brew formula just to get the gnome-terminal seems overkill, when it is already available.

    Regardless, we were having trouble building gnome-terminal with FinkCommander, that is until we removed all brew installed component references from environment variables; we certainly had to take /usr/local/bin and /usr/local/opt/gnu-tar/libexec/gnubin out of $PATH, and just for kicks, we made sure ${DY}LD_LIBRARY_PATH didn't point into /usr/local/lib, etc. This allowed gnome-terminal to build & install successfully with FinkCommander.

    Further, we have software which we want to install via brew, fink, and port - but brew does not play well with others. This has led to the more general question: Is it enough just to toggle path and environment variables to switch between brew and fink/port build environments and installations? We know we need to hide brew from fink via environment variables when building gnome-terminal with FinkCommander, and the assumption is that for some brew defined formula, the reverse is true.

    What in general must we do to have the best of all three worlds? That is, what to do to have all three, brew, fink, and port, built and installed in parallel? Because all the managed packages were built from scratch, each package should know where their own dynamically linked libraries are located. Is it enough to jumble around the $PATH, $MANPATH, & $DYLD_LIBRARY_PATH environment variables on the fly to put one installation in front of another to use its defined tools? Are we missing anything?

    • Answers
  • Raim

    Let me answer that from the MacPorts perspective I come from, as these problems of co-existing software management tools are not unknown there. Most importantly, there simply is no way to remove /usr/local from the default compiler search paths. This may lead to problems with some builds, especially during a multi-architecture +universal compilation.

    In the beginning of the project many years ago, MacPorts switched to /opt/local in order to avoid problems with other software. Total isolation from /usr/local does not seem to be possible at all by compiler configuration flags alone. Unfortunately, Homebrew developers deliberately ignored this and chose /usr/local as their default. While it sounds like a good idea as it would be already listed in PATH, in the default configuration /usr/local/bin only occurs after /usr/bin, making it impossible to overwrite any command line tools. So there is no advantage of using /usr/local at all.

    Best solution is to either install Homebrew to any other path (for example /opt/homebrew), or to rename /usr/local temporarily before building and rename it back afterwards:

    sudo mv /usr/local /usr/local.off
... # do your compilation work
sudo mv /usr/local.off /usr/local

    As a side note for the future, while MacPorts in its current version is already using a sandbox for all builds, there are improvements in this area coming for version 2.3.0 or later. The new trace mode currently in development would allow to limit all file access to those files required for the particular build task only, hiding locations like /usr/local and /sw completely from the build process. However, that won't help with other tools unless they adopt this feature as well.


    • Related Question

    osx - How to install software packages on a Mac? (MacPorts, Fink, anything better?)
  • Ben Alpert

    On my Mac OS X machine, how would you recommend I install command line software and other packages? I've been using MacPorts and it always seems quite slow, presumably because it has to compile the packages on-the-fly.

    I'd much prefer a package management system that has binary packages, saving me the need to compile things every time I want to download something new. I think Fink has binaries for some of the packages, but I usually see MacPorts recommended as the system to use.

    Which do you think works better and why? (Or is there another system that I haven't heard of?)


    • Related Answers
  • slhck

    I used to use Macports because:

    • It is generally more up to date
    • Macports seems to be more common / popular
    • Everyone else I work with uses it

    When I did my own research on this topic when I got my MBP last fall, Macports seemed to be most commonly recommended for reason #1 above, hence reason #2 (and probably reason #3).

    Compiling every package doesn't bother me. It is usually fast enough that it doesn't interfere with work. But you might look into port binaries if you're going to use macports.

    However, I quit using Macports.

    There is also a new tool in this space called Homebrew. I switched from Macports to Homebrew a few weeks ago and I'm pleased as punch. I like:

    • It doesn't install duplicate libraries - it uses the system's existing libs.
    • It installs in the user home directory - no sudo required and backs up to TimeMachine.

    Homebrew works on Leopard or Snow Leopard, though sometimes Formulas need to be modified on Leopard.

    I think all my coworkers have now switched to Homebrew. It is also gaining traction in the Ruby and Erlang (and possibly other OSS?) communities.

  • Legion

    You don't have to pick between the two.

    MacPorts installs software to /opt/local. Fink installs to /sw.

    Both leave the Darwin base system untouched, and the two can co-exist peacefully.

    Fink's binary packages are great, but they aren't always up-to-date. I tend to use Fink when they've got an up-to-date package, and I build from MacPorts if they don't.

    Some packages are only on one or the other, so it's handy to have them both at the ready.

  • dmckee

    Fink partisan here, because

    • The packages of interest to particle physicists (like me!) are very up-to-date
    • I use debian on my linux boxes. The fink command line is a lot like aptitude, and I'm used to the dpkg underpinnings
  • weakish

    If you only install a few programs, anything (fink, macports, homebrew) will be fine.

    But if you are a heavy user, I think only macports is suitable. fink's package is a bit too old. homebrew is a too young project.

    Also, recently I've heard someone using pkgsrc on mac os x. And I may give pkgsrc a try. (I am using macports now, and have 418 ports installed currently.)