38

I am using Fink to install Unix apps on my mac, I just came across Homebrew and saw some good reviews about Homebrew.

So, my question is:

  1. What package manager do you guys use for Mac?
  2. I use Fink currently, so will the shift from Fink to Homebrew be really worth it?
  3. If 2. is true, then why?
zengr
  • 1,354
  • 2
  • 16
  • 27
  • I moved from Fink to Homebrew, the best thing about homebrew is you can install it anywhere, so no sudo required. Which I personally don't prefer. Any suggestions about macports? – zengr Jul 02 '10 at 16:36
  • After using brew, I feel there are few packages which are not there. like "meld" is on macports but not on brew. – zengr Jul 09 '10 at 08:06
  • meld is now offered in brew – Antony Jul 26 '12 at 19:57
  • Related questions on [stackoverflow.com](https://stackoverflow.com/q/21374366) and [apple.stackexchange.com](https://apple.stackexchange.com/questions/32724) – cachius Sep 24 '22 at 16:29

3 Answers3

18

IMHO, the problem with Homebrew is it tries to use /usr/local in a way it was never meant to be used: owned by a user other than root. While I understand the homebrew developers take care not to munge with anything else in /usr/local, nothing else that installs to /usr/local will do the same for Homebrew. This can cause problems, and has for me... usually permissions issues that result from installing other software that sets permissions on /usr/local/ based on "how they should be". You'll never see another software package expecting /usr/local/ to be owned by a single user other than root, so why does Homebrew? Why not just use ~/bin?

Also, a little known fact about why Fink & MacPorts compile their own libraries:

There are several reasons why MacPorts uses its own libraries. It makes ports more consistent across different versions of Mac OS X. For example, if we can rely on openssl 1.0.0 from MacPorts, we don't have to test every port that needs ssl for every available openssl installation. Apple's software tends to break from time to time (e.g. openssl refuses to build with an old zlib, but for awhile Apple shipped the old headers of the vulnerable zlib version). Even if Apple's versions aren't broken, they're rarely up-to-date. Apple has a habit of not updating the libraries in Mac OS X until absolutely necessitated by a security vulnerability.

The drawbacks of this policy are minimal: Wasting a few megabytes for e.g. a Python installation is next to nothing if you have a multi-gigabyte hard disk, and the time required to build the additional ports decreases as computers get faster.

So while Homebrew is faster to install what you want, it can have other bad side effects from using pre-built Apple system libraries.

Again, I hate to dig against Homebrew. I like the software & I think it's great for some things, but it has it's downfalls as is currently.

Community
  • 1
churnd
  • 4,898
  • 26
  • 24
  • Just run it as root if the permissions have changed? It has happened for me, there's an error message, and I `sudo`ed. What's the problem? – Daniel Beck Dec 27 '11 at 15:29
  • The problem is according to them, that's not how it's meant to be done. Their "recommended way" is not right. – churnd Dec 27 '11 at 15:35
  • They do make a convincing case against excessive `sudo` use though. It just fails once you start installing your own programs into the same prefix. Most software can handle being installed somewhere else, so maybe you did it wrong? Fink and Macports just created their own directory hierarchy to sidestep this issue... – Daniel Beck Dec 27 '11 at 15:37
  • 8
    No I didn't do it wrong. The practice of having /usr/local owned by a regular user is wrong. You will not see that with any other *nix based software, ever. Every other software package I've seen respects root:wheel ownership of /usr/local. Why even take over /usr/local at all? Why not use /opt/homebrew & link things to /usr/local/bin or /usr/local/lib if you have to (albeit with sudo)? Give the user the choice, but don't break things if they want to keep things separate. Set up their environment accordingly based on their choice. Everything co-exists peacefully. Win-win. – churnd Dec 27 '11 at 16:09
  • I am aware of that, thank you. Just use a different prefix then. Last time I checked, the prefix was customizable. The defaults are for what they consider their average user. For 90+% of users, it's good enough, as they just don't compile and install their own software to `/usr/local`. They don't even have multiple user accounts either, so the ownership is a non-issue there and actually improves the whole experience. – Daniel Beck Dec 27 '11 at 16:36
  • Also, Homebrew can both be used as root (although they advise against it), which I have done for months without issues, and has `brew doctor`, which verifies ownership and tells you if some are set differently. It's simply something you need to be aware of, just like the sharing of libraries with OS X, or Macports' different behavior pulling down every base library again. – Daniel Beck Dec 27 '11 at 16:43
  • It's not just about compiling/installing. Some OS X packaged installers install to /usr/local (nmap, juniper vpn, etc) & installing these after homebrew will bork the permissions. It's not about what you *think* people do (90%?? ...oh please), it's about what is considered good practice on a unix system. If it's meant to be run as a single regular user, it belongs in `~/bin`. I'm aware homebrew can be run in different places & as owned by root. The problem is they strongly advise against it & warn things will break if you do. Not very user friendly. – churnd Dec 27 '11 at 17:21
  • Again, that's what `brew doctor` is for. `~/bin` does work for the simple reason that it'll annoy the users that already use it, differently (sounds familiar?), and the fact that not all they do is provide binaries. They need a more complete folder hierarchy. // So you don't think most users of e.g. Homebrew *don't* install software to `/usr/local`? – Daniel Beck Dec 27 '11 at 17:26
  • Also, you mention *what is considered good practice on a unix system*. Please explain the absence of `/srv`, `/mnt` and `/home` on OS X, as specified in the FHS. If you have a different reference that is not already violated by OS X's own convention, please share it. – Daniel Beck Dec 27 '11 at 17:34
  • If homebrew had used `~/bin` from the get-go, everyone would be happy except those who have multi-user systems, amiright? It's pointless to make that argument. In response to your second (last) comment, those locations typically don't exist on BSD systems, but rather linux systems. Both fall under the unix category, but are different breeds of an OS entirely. The FHS doesn't apply to BSD systems, only linux. OS X is BSD based. – churnd Dec 27 '11 at 18:31
  • Again: `~/bin` is sometimes used by *users* for their own programs. Just like `/usr/local` is. What would be better with it? And again `~/bin` just doesn't cut it semantically: You need more than binaries. Or do you also propose use of `~/lib`, `~/sbin`, `~/etc`, `~/include` etc? // Regarding the file system: You make a good case against my reference. Do you have one of your own? – Daniel Beck Dec 27 '11 at 18:59
  • 1
    This is getting silly. I'm commenting one last time & leaving it at that. You're contradicting yourself. The whole point of Homebrew is that it uses pre-existing libraries that OS X already has. Putting what Homebrew installs in `~/bin` is functionally no different than `/usr/local`. The stuff it requires to run (lib, etc, sbin, include) are already in every users environment by default on OS X. That's the "beauty" of it. – churnd Dec 27 '11 at 20:14
  • 1
    Regarding the filesystem, there isn't a heirarchy standard for BSD systems like FHS I'm aware of. I was merely pointing out that `/usr/local` is typically not owned by any user other than root. That is true for BSD & Linux alike. OK that was two comments, but only because it went over the limit. FIN. – churnd Dec 27 '11 at 20:14
  • @churnd I find it interesting that Homebrew has finally admitted fault on this and in the new version released a week or two ago, has restored the default permissions to /usr/local ... the battle is over ... what they did to get around this, was that they put their user:group permission on directories inside of /usr/local ... but not /usr/local itself. lol ... also like Homebrew but they were always wrong on that one point. – oemb1905 May 10 '17 at 12:43
15

I prefer homebrew due to its simplicity/speed -- my tools seem to be getting updated quickly at the moment.

It's the most painless source based package management tool I've used and development seems quite active. What more could you want?

(Yes, all the missing apps)

CoffeeRain
  • 477
  • 5
  • 11
Jacob
  • 179
  • 2
7

I use both Fink and Macports. Both work like a charm.

But I might recommend Homebrew to not so expert user who are just migrating from windows, due to its apparent simplicity.

mefepe
  • 109
  • 2
  • 3
    Another vote for Homebrew. Finally a package manager that doesn't feel like installing an entirely new OS. – elasticrat Nov 21 '10 at 14:21
  • 1
    How can simplicity go against Homebrew for expert user? I never used Fink, but Macports is no brainer, even for newbies – Antony Jul 26 '12 at 19:58
  • it's 2016, and back around 2010 or so I stopped using fink, because it just stopped working for me. I started using macports, and it still works great. Never tried homebrew, because of its tendency to do weird non-unixy things (philosophically) wrt sudo and /usr/local (in short: installing packages should require sudo, and it shouldn't use /usr/local), and macports might work better for my older macs. So far, my mac acts just like my linux shell, thanks to macports, which is the goal. – michael Oct 06 '16 at 11:22