9 ms·

Is there a reason to use either of those systems over homebrew? Since homebrew seems to have a lot more community support now.

verandaguy 13y ago
I could be wrong, but I believe MacPorts has more ports in the default repository at the moment. Not sure about Fink. But yes, arguably, `brew` is moving forward very quickly.
- zbowling 13y ago
  MacPorts is full of useless junk. MacPorts will install a new sandboxed python, ruby, perl, etc when just want to get wget (the built in versions are fine!). The libraries are all broken out where brew keeps them simple and a lot of the packages are old silly packages that no one on the Mac really cares about (every single GNOME library for example). brew isn't just moving forward quickly, it has really just out right replaced MacPorts and anyone still using MacPorts is living in 2007.
  - pjl 13y ago
    MacPorts does not use system libraries for good reasons: "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." [1] [1] https://trac.macports.org/wiki/FAQ#ownlibs https://trac.macports.org/wiki/FAQ#ownlibs
mtrn 13y ago
I used all three at one point in time. What I love about homebrew is that the tedious work of maintaining a sane package repository is distributed over many shoulders (3429 at the moment) - and those who contribute most of the time do really care about the packages they are watching over. I haven't found an easy way to add/update packages to finc or macports, but I could contribute to homebrew within 5 minutes. I wish we would see more work distribution patterns like this in fields outside code/programming.
_delirium 13y ago
Once you start piling up some dependencies (vs. self-constained apps), I found homebrew more of a mess, while MacPorts more or less worked as I'd expect. The thing that drove me off Homebrew was dependency-hell with different versions of Python packages, while MacPorts pulled in the right versions of all the dependencies (it can even handle needing multiple versions of NLTK/SciPy/etc. installed in parallel, if different ports depend on them). This is perhaps the flipside of the reason many people prefer Homebrew: it tends to build against the base OSX stuff, while MacPorts tends to pull in its own parallel world of dependencies. IME the latter works more reliably, though it takes up more diskspace. But, Debian's package management works better than either of them, so I've sort of been moving towards doing any kind of unixy work in a VM and treating OSX as just a desktop.
- JonnieCache 13y ago
  It's possible to end up in a different circle of dependency hell with macports, where it insists on installing 10 different versions of everything at great length, when you already had a perfectly good one. If I'm not a python or perl developer, I don't want to compile many different point releases of those language ecosystems just to run some little utility scripts. And then of course everything is connected to everything else, so you can end up trying to solve graph theory problems when you're meant to be working. Battle-hardened *NIX admins rightfully laugh at this attitude, but for a lot of web developers who use their laptops as a "sharp tool" and do all the heavy lifting in linux vservers, it makes sense to have a slightly laxer approach to package management. (and then there's the increasingly common cases of build scripts just being broken on macports, because it receives less and less community attention now. this can combine with the above dependency graph problems to produce situations where it's easier to just nuke /opt/local and start again.)
  - lae 13y ago
    I'm a *NIX admin and actually, when it comes to OSX I'd rather go the VM route than homebrew/macports (either way, I don't run OSX daily).

verandaguy 13y ago

I could be wrong, but I believe MacPorts has more ports in the default repository at the moment. Not sure about Fink. But yes, arguably, `brew` is moving forward very quickly.

zbowling 13y ago
MacPorts is full of useless junk. MacPorts will install a new sandboxed python, ruby, perl, etc when just want to get wget (the built in versions are fine!). The libraries are all broken out where brew keeps them simple and a lot of the packages are old silly packages that no one on the Mac really cares about (every single GNOME library for example). brew isn't just moving forward quickly, it has really just out right replaced MacPorts and anyone still using MacPorts is living in 2007.
- pjl 13y ago
  MacPorts does not use system libraries for good reasons: "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." [1] [1] https://trac.macports.org/wiki/FAQ#ownlibs https://trac.macports.org/wiki/FAQ#ownlibs

mtrn 13y ago

I used all three at one point in time. What I love about homebrew is that the tedious work of maintaining a sane package repository is distributed over many shoulders (3429 at the moment) - and those who contribute most of the time do really care about the packages they are watching over. I haven't found an easy way to add/update packages to finc or macports, but I could contribute to homebrew within 5 minutes. I wish we would see more work distribution patterns like this in fields outside code/programming.

_delirium 13y ago

Once you start piling up some dependencies (vs. self-constained apps), I found homebrew more of a mess, while MacPorts more or less worked as I'd expect. The thing that drove me off Homebrew was dependency-hell with different versions of Python packages, while MacPorts pulled in the right versions of all the dependencies (it can even handle needing multiple versions of NLTK/SciPy/etc. installed in parallel, if different ports depend on them). This is perhaps the flipside of the reason many people prefer Homebrew: it tends to build against the base OSX stuff, while MacPorts tends to pull in its own parallel world of dependencies. IME the latter works more reliably, though it takes up more diskspace. But, Debian's package management works better than either of them, so I've sort of been moving towards doing any kind of unixy work in a VM and treating OSX as just a desktop.

JonnieCache 13y ago
It's possible to end up in a different circle of dependency hell with macports, where it insists on installing 10 different versions of everything at great length, when you already had a perfectly good one. If I'm not a python or perl developer, I don't want to compile many different point releases of those language ecosystems just to run some little utility scripts. And then of course everything is connected to everything else, so you can end up trying to solve graph theory problems when you're meant to be working. Battle-hardened *NIX admins rightfully laugh at this attitude, but for a lot of web developers who use their laptops as a "sharp tool" and do all the heavy lifting in linux vservers, it makes sense to have a slightly laxer approach to package management. (and then there's the increasingly common cases of build scripts just being broken on macports, because it receives less and less community attention now. this can combine with the above dependency graph problems to produce situations where it's easier to just nuke /opt/local and start again.)
- lae 13y ago
  I'm a *NIX admin and actually, when it comes to OSX I'd rather go the VM route than homebrew/macports (either way, I don't run OSX daily).