Hacker News Reader

Comment by 616c | Hacker News Reader

I do not wants to flame, but is there a reason people dislike Macports so much. I tried Homebrew when it was 1-2 years old, but stuck with ports bc it was so stable, compiles from source, and I never heard a serious problem.

I heard the opposite complaint on the net, but almost all Macports hate was from many years before.

I am the only one who chose not to rely on Homebrew!?

View on HN

I prefer Homebrew over Macports, because the Homebrew default is to use the stuff your system already has. Macports always wants to pull in (newer versions) a bunch of stuff that's already in OSX.

There's benefits to both approaches. However, I really only need a few extras on my OSX laptop, and I don't really want to end up compiling dozens of extra stuff just to get the latest version. Sometimes I want to force that new version, but only if there's specific functionality I'm after. Others really want to get the latest and greatest of everything constantly...

I like Macports a lot more. I've never had an issue with any of the packages really besides a few esoteric ones that failed to build or hadn't been updated in a while (and they are usually easy to by updating the portfile). I prefer the segregated environment of macports too, you won't overwrite any system stuff. I got the impression that homebrew wasn't a terribly well thought out tool and was a bit lazy. There's a lot of 'github' culture there which I'm wary of (and by github culture I mean half finished stuff and fancy looking projects lacking rigor). Case in point, it annoys me that their slogan is 'the missing package manager for OSX'. Macports had been around long before they were. I only sometimes wish that Macports had better binary package support.

My understanding is that Homebrew does not clobber any system defaults — works with the OS, not against it. I could be wrong, though.

No, MacPorts is actually more sane in this regard because it build it's own set of dependencies instead of relying on anything the system provides. This makes it a more soundly designed tool, IMO.

Homebrew also recommends using /usr/local as the root which I think is just plain bad advice, but it is simple enough to change it to something else.

Why is /usr/local bad advice?

Because /usr/local doesn't belong to homebrew and is not appropriate for homebrew to commandeer.

MacPorts was originally written by the BSD team at Apple; if /usr/local was where a packaging system was supposed to stuff itself on OS X, they would have used it -- instead of /opt/local.

The co-opting of /use/local breaks all kinds of stuff -- for instance, /usr/local/lib is in the default linker search path and can't be removed, which means that trying to not link against homebrew libraries requires some pretty evil hacks -- such as library symbol interposing to hide /usr/local from stat(), etc.

I disagree. / is where the stuff needed for single-user mode gets installed. /usr is where the OS's userland stuff gets installed. On Linux systems this includes everything that you get from your package manager, because this is considered to be part of your system. /usr/local is wher you install your own packages. For example, if I'm installing something from source, that's where I'm going to install it. Or if I'm building my own project, I would also install it there.

On a Mac, there is no system-blessed pacakage manager - the official packages are pre-installed on your Mac and only change when you get an OS update. They tend to be installed in /Library or ~/Library. All of the add-on package managers therefore play a role much closer to that of hand-installed source. It's logical that they install to /ur/local. In particular, one of my main use case for package managers is when I want to try out a package that has a whole bunch of dependencies. I might want to compile the package that interests me by hand, as I need to tweak the config, but I don't want to have to do the configure-make-make install dance for the 30 packages that it has as dependencies. That's where homebrew / MacPorts comes into the picture, they save me that work. But they should be installed into the same hierachy as the package that does interest me, as they are at the same level of "officialness".

One last thing. I know Fedora, Gentoo and MacOSX fairly well, and I have also worked a fair bit on a hand-rolled linux distribution. None of them ever had /usr/local/lib in their LD_LIBRARY_PATH by default, I've always had to configure that in my .bash_profile. This is exactly what you would expect, by default the directory should be empty, so why add it to the default LD_LIBRARY_PATH, that doesn't make any sense.

> /usr/local is wher you install your own packages. For example, if I'm installing something from source, that's where I'm going to install it.

Right, that's what it's for, it's also why a 3rd party package manager shouldn't use it.

Homebrew is installing stuff from source, though. It's automating the task of me doing it.

Well, it usually installs from source, but that's not really the point. It's a package manager, it is trivial to give it it's own home, (and thankfully they made that an easy thing to do), but to throw it in that /usr/local bucket by default? It seems like a decision that requires real justification and the reasons I have seen seem pretty weak.

I mean, in the end it seems like almost nobody cares, but it's always been a pet peeve of mine.

I get what you're saying, but /usr/local is where I install stuff. I'm happy with having the thing that does little more than untangle my dependencies before running `make` for me with sane defaults use it too.

I expect to find system-specific applications in /usr/local. I get the argument otherwise, and it has merit, but not enough to not do it, if you get me.

Can I ask what you use your package manager for? My experience on the Mac is that it's mostly used by developers that want to install a package and don't want to have to manually install the 30 other dependencies by hand. For that use case, installing the dependencies along side the module that you actually wanted seems like an eminently reasonable thing to do, and certainly in my case it's pretty much exactly what I want from a package manager on the Mac. I assume if it bugs you that you have a different use case from mine. I would be interested to hear what it is (have I been missing opportunities on my Mac all this time???)

> On a Mac, there is no system-blessed pacakage manager ...

Which is one very big reason why commandeering /usr/local for a single package manager is inappropriate; it means that your 3rd-party package manager cannot share the system with any other 3rd-party package manager.

To re-iterate -- the BSD team, who maintained hier(7), very intentionally didn't put MacPorts in /usr/local.

I haven't used macports in quite a while, but I switched because homebrew was more up to date. It might not be the case now though.

Nope, I'm a Macports guy as well, never had any serious problems with it. I wish it was possible to run both though because there are packages exclusive to either that I would like to run.

I use MacPorts. I tried Homebrew about a year ago, it worked fine, but I could not see the benefit. The current MacPorts is pretty up to date, at least for my needs. Pretty trouble free…

I stopped using Macports for two reasons. First, it was taking a long time for some of the ports to get up to date. That doesn't seem to be a problem now, but it was. The second reason is that it insists on using its own versions of tools that OS X already has. I'd prefer not to install new versions if I don't have to. I understand their reasoning, but that's why I don't use Macports.

I think homebrew is much easier to contribute to. I started using it when I wanted something that neither Macports nor homebrew had at the time, and it was very simple to add it to homebrew. It seems like things are generally more up to date and comprehensive in homebrew, and I think it's because of how easy it is to add things.

I would think you can't find recent Macports complaints because nobody uses Macports. I didn't even realize it was still being updated at all. I stopped using it many years ago because it was frequently long out of date and broke in ways that I found impossible to fix without wiping everything and starting over.

I switched to Fink, which broke occasionally but I was usually able to rescue it without too much hassle.

Eventually I stopped using Fink maybe a year (or two?) ago in favor of homebrew, and have not had any serious problems since. brew's structure combined with 'brew doctor' and a vast and frequently-updated array of available packages seem to have done a pretty good job of avoiding the "can't get there from here" problems I had with fink and macports.

Huh. I had no idea. I've been using MacPorts for what must be a decade, or close to it. Tried Fink a few times, never had any luck -- but never had a reason to find anything new (brew). I guess the Ports versions of everything I use are "good enough". If it ain't broke, and all that.

I am absolutely no kind of programmer but I prefer to compile from source on my own, when I can. For example, the first thing I did yesterday after clean installing Yosemite Beta 4 was to compile Scrypt.

Can I perhaps ask why? Is it a trust issue that you don't like accepting a prebuilt binary from some random on the internet?

I just enjoy the control.

That''s quite witty! Do you also make all of your bread from the base ingredients too? :-)

For example, I like running the latest version of Vim (OS X is often behind). Compiling from the source, I can control what the binary is named (to avoid a name collision with the built in Vim), I can control the features (--with-features), and I can have it install to a directory of my choosing (~/Applications, where I also have scrypt install).I also install Lame and FLAC this way.

As for bread, no, I am horrible at cooking!

That's quite wise, particularly regarding the feature selection. Such joy from having the source!

I suppose I never run into this problem because I don't use the software to its full extent and therefore don't miss any features! I must be lazy.

I don't use either. I build my stuff manually, and that way I also contribute upstream if there is a problem with some software not building on Mac OS X out of the box.

Macports was perhaps necessary a while back, when most people didn't realize Mac OS X was just another BSD based UNIX. Now that the word is out, most software builds without a hitch.

And honestly if you can't download a source tar archive and compile it yourself with your own customizations, then don't call yourself a hacker.

People don't really dislike Macports, they just like shiny new things on github.

Homebrew isn't exactly new

Homebrew was new 5 years ago when a whole new generation of Mac-using front end developers discovered the command-line (and git, and tmux…). MacPorts worked perfectly well but hey! how can an old tcl-based, svn-using package manager compete with a new ruby-based package manager that's on GitHub?

Reply on news.ycombinator.com