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.

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.

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.

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

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

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

> 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.)

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.

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.

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.

Agreed, I don't understand why so many people use homebrew instead of macports. Macports seems to be immune to so many issues that complicate homebrew, and I love that it keeps everything in its own dir, '/opt'. Easy to see what it installed, and easy to uninstall (rm -r /opt). The commands are also easier for me to remember -- no awkward, overstretched analogy.

I often help people start hacking on open source projects and I can't tell you how many times they've made a mess with homebrew, nothing works. Replace homebrew with macports and their problems are solved, rarely to return.

Maybe in some cases homebrew installs something a bit faster, but it's rarely a meaningful amount of time and it doesn't make up for all the time spent fixing homebrew when it messes up.

"Agreed, I don't understand why so many people use homebrew instead of macports."

This might seem very odd to you, and maybe I'm a weird outlier, but after having used macports for years, and installed it many times on many different systems, the requirement for full blown xcode is quite a turn-off and makes any alternative interesting and attractive.

The OSX system I am typing on now should have macports on it, and I sort of need it, but I just never have time to devote an hour to app store -> dev login -> xcode install -> blah blah -> macports.

Just FYI anyone can download XCode from the App Store, it doesn't require a "dev login". (Agree it would be nice if MacPorts only required the XCode Command Line tools like homebrew, it would be one less download.)

I was going to try macports but the XCode download turn me off, why it can rely only on the command line tools?

Don't many of the dev command line tools, like clang, come from xcode?

The command line tools package includes all you need to compile with and is far smaller than Xcode. I think it's about 150mb.

Yes, that's true, and of course that's what I'd like to do (command line tools only), but last time through that was yet another ten minutes to find the correct xcode and match things up and so on ...

I fully accept that I'm just being a complainer here, but in answer to the parents question, those are the mental blocks for me.

It can, in theory. In practice, there are some ports that actually need a full Xcode installation to build, and those would just fail without Xcode.

In an ideal world, there would be a dependency declared on Xcode for all those ports so MacPorts would work with command line tools only and fail gracefully whenever Xcode is required. However, that is currently not the case because nobody implemented an easy and automated way to tell whether a port will build fine without Xcode.

I'd advise caution doing an `rm -r /opt`, and suggest it might be more precise (and generally better) to `rm -r /opt/local`. Macports will typically install to /opt/local, and in my experience, stuff like vagrant and certain VPN clients will install into subdirectories of /opt.

In fact there was a version of Cisco VPN client that blew away /opt (and all of my macports) on first install!

I started using Homebrew when I was a new Mac user because MacPorts didn't work out of the box through the corporate firewall. It's kept working for me so I haven't found a reason to try MacPorts again.

Macports never worked for me. I'm not sure if I'm not smart enough to make it work, but there was always something where updates would fail, or some package was broken.

Homebrew just worked, and when it breaks, brew doctor is typically spot-on in telling me how to fix it. I've never had the time to figure out why MacPorts gave me trouble.

For a while at least, when Homebrew was getting popular, MacPorts seemed highly moribund and destined to be abandoned. It seems to have recovered some life since then, though.

Homebrew got big in the ruby community first -- I distinctly remember trying to get Rails to work with MacPorts' MySQL install and the whole thing turning into a clusterfuck, and then someone introducing me to homebrew where the whole thing just worked smoothly because every other Rails dev was walking the same path.

Homebrew exploded among ruby devs because adding new recipes to it was a couple of orders of magnitude easier (just write a few lines in a simple ruby DSL and send a pull request on Github) than MacPorts (hack about in bash cruft and then, what, open a ticket somewhere with a patch to ask for someone with an SVN commit bit to commit it, I guess?

Nothing really changed in terms of MacPorts liveliness; development continued as it always had, and Homebrew has gradually learned why MacPorts adopted the solutions it did -- usually the hard way.

Homebrew's popularity was built on incredibly negative (and often dishonest) marketing that painted MacPorts as old and busted.

For example, Homebrew touted the security advantages of not using sudo, as compared to MacPorts, ignoring the fact that:

1) MacPorts dropped privileges when performing port builds to an unprivileged user, providing generally higher security than running with the current user's full permissions.

2) MacPorts has always also supported non-root installations that didn't require sudo.

Dishonest marketing? Really? Homebrew, a free tool was out spreading lies about MacPorts? That's ridiculous. When pretty much every major Ruby shop uses Homebrew, why would I want to kick around with MacPorts? I trust Thoughtbot, Pivotal, etc, far more than the two guys actually using MacPorts. Perhaps Homebrew 'won' in that particular community because it was better, ever considered that? Wide community adoption is a far bigger incentive to use a tool over potentially trivial conceptual disagreements.

> Dishonest marketing? Really? Homebrew, a free tool was out spreading lies about MacPorts? That's ridiculous.

Ridiculous? Homebrew's marketing tagline was "MacPorts driving you to drink? Try homebrew!". The (obviously uninformed) slams of MacPorts and Fink didn't stop there.

It was the first time I'd ever seen negative marketing against a competing OSS project.

> When pretty much every major Ruby shop uses Homebrew, why would I want to kick around with MacPorts?

That wasn't the case then, was it?

> I trust Thoughtbot, Pivotal, etc, far more than the two guys actually using MacPorts.

Yes, this is the kind of specious negative marketing Homebrew specialized in.

> Perhaps Homebrew 'won' in that particular community because it was better, ever considered that?

Sure, I considered that. Then I objectively reviewed Homebrew's claims.

> obviously uninformed...

Perhaps you never didn't use macports or fink a few years back?

They were terrible.

Perhaps, now, they're slightly better, but there was a time about oh... 2 years ago, when macports specifically actually made me want to punch my computer.

I can't speak for anyone else, but I can say, that for me, personally, every complaint leveled against them was absolutely spot on.

The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr. SIP doesn't block /opt; if it did, MacPorts would also have broken, sudo or no sudo.

SIP doesn't block /opt for the exact reason MacPorts relies on /opt: It's not part of the existing operating system. In other words, this situation isn't just good luck for MacPorts, it's a direct result of the design decisions behind MacPorts, and the design decisions behind homebrew.

> The problem is even _root_ can't add the missing /usr/local, because SIP prevents even root from touching /usr.

This goes against all that I have read and my own experiences with the betas. Maybe Apple changed something last minute. See here: http://www.macworld.com/article/2948140/os-x/private-i-el-ca...

The specifics of System Integrity Protection are that no user, application, or process will be able to write files or modify files in the root System folder or the /bin, /sbin, and /usr directories, which are hidden by default in OS X’s Finder. The /usr/local folder remains accessible, however; it’s a long-running convention in Unix and variants as a place to stash material and software that individual users rely on.

The bit you quoted doesn't contradict what the OP stated, if /usr/local _does not_ exist, not even root can create it.

If it exists, we can use it as before.

Considering how many times I've installed OS X, I can't recall if /usr/local is there by default (excluding 10.11 for the moment). Will have to do another few installs and check.

On my Yosemite system /usr/local was created by default when the OS was installed.

I can confirm that /usr/local is there by default on a clean install of El Capitan

Perhaps the easy of writing recipes, combined with good timing (Ruby was all the rage), is what made people go to homebrew.

Unless you're making iOS software, why not just use Linux?

I always have Ubuntu Server running in the background in a VM, so I get the desktop experience that I prefer (Windows) and a better Unix experience than OS X provides.

OS X has always provided a fine Unix experience for me.

If you're OK with Apple taking away root privileges on your box, then I guess a lot of things that are fine with you are not going to be fine with other people.

Enjoy using Apple's computers...and they are Apple's, not yours because if they were, you'd be in control.

Feel free to disable sip, or just unprotect the folders you don't want protected (although the latter would get wiped out after updates).

Sounds like a great UX.