Hacker News Reader

Comment by robbles | Hacker News Reader

The reason I switched to HomeBrew, after attempting to use MacPorts for several years, was that the formulas all actually worked and resulted in installations that weren't horribly broken and/or reliant on 10 different additions to my PATH and environment variables. Homebrew may have some questionable policies, but at least it works well and has recipes that successfully compile. It also tells you why recipes aren't compiling.

View on HN

> reliant on 10 different additions to my PATH and environment variables

MacPorts adds exactly two directories to the $PATH: export PATH=/opt/local/bin:/opt/local/sbin:$PATH

No new environment variables are added. The only required environment variable tweak is the PATH one above.

(In a corner case, where you have modified your MANPATH in your bash profile, which almost no one does, you may want to add another variable for man pages, but normally this works fine out of the box without an env var. The other optional env var is for versions of OS X older than 10.5.)

(FWIW, I've had the opposite experience — MacPorts rarely fails, every time I need to switch to Homebrew, several times now, I get a fail right out of the gate with whatever thing wasn't available or not working on MacPorts.)

I realize this is anecdotal, but my experience has been much more like robbles' than mapgrep's.

One issue is that the MacPorts built versions of things don't always integrate in a nice way with other parts of the system. For example, it used to be the case (and may still be) that LibSDL built under MacPorts would hard-code the absolute build path used to build it into the shared object, so that the frameworks wouldn't work if you moved them (e.g., if you wanted to use the frameworks to distribute an SDL-based game to your friends). This appears to be a choice that the MacPorts devs made explicitly, since standard source builds of SDL don't do that, and the standard SDL binaries don't do that.

I understand there are trade offs here, but the ones the MacPorts devs chose were not the ones I would have wanted. Homebrew, for better or worse, makes it much easier to make local changes to recipes, if you disagree with what the devs choose. However, I find that most of the disagreements I had with the MacPorts folks just haven't shown up with Homebrew.

There used to be nice documentation online about frameworks but from that I learned:

$ man install_name_tool

Edit: I looked in one of my Makefiles:

  install_name_tool -change \
    /bar/baz/lib/libfoo.7.dylib @executable_path/lib/libfoo.7.dylib a.out

Yes, that is exactly what I did. It still took forever to find the right Google keywords to find what I needed, and figure out the right command line invocations. And I would need to re-learn it all over if I ever upgraded SDL. By comparison, downloading the pre-packaged binaries from LibSDL.org takes all of 10 seconds...

You should also look at otool as well while you're at it. They're useful commands, just difficult to discover unless you already know what you're looking for.

Having both of those directories in your $PATH would definitely cause problems, you're loading two different collections of installed ports at the same time.

Not clear on your meaning. The fact that the two directories have completely different ports inside of them is the reason you want to add both to the PATH.

The line I pasted, from my own .bash_profile, is identical to the recommended approach: https://guide.macports.org/chunked/installing.shell.html

Just one collection of ports. Different kinds of binaries go into different directories, by convention. But all are managed by MacPorts.

Ditto. And Homebrew's policy of avoiding installation of built-in packages by default means that you don't accidentally break your whole system when MacPorts shadows a critical core package.

I can't fathom how MacPorts could ever break your whole system.

- MacPorts' /opt/local is not in any of the default system paths.

- MacPorts uses sandboxing to ensure that builds can't stomp anything outside of /opt/local

Not sure about the above poster, but the only times I've heard folks claim that macports broke their system was when they were setting DYLD_LIBRARY_PATH.

edit

should be noted you really ought not do this and if you absolutely have to you should use DYLD_FALLBACK_LIBRARY_PATH

Run otool to check but Apple at least builds their stuff right and it's getting harder for companies to shoot themselves in the foot like that cause Xcode automatically does the right stuff for devs that are rushed not careful.

Maybe you didn't know about port select (like me when I started using Macports):

http://stackoverflow.com/questions/6612009/macports-port-sel...

I switched after having to blow away my Macports directory and start over four times in the first year I used it due to unrecoverable levels of brokenness. ~4 years of HomeBrew later and the worst I've had to do is `chmod`.

Having used both, I agree. Homebrew is just better. I have not had to start from scratch with Homebrew. I had to start from scratch multiple times with MacPorts once I had installed a critical mass of conflicting packages.

If you've been using Homebrew for 4 years, you probably missed MacPorts' adoption of binary packages, automatic detection+repair of broken library linking, sandboxing of builds, etc.

That's resolved all of the fragility (and heinous build times) that previously existed.

Reply on news.ycombinator.com