4 ms·

I was using MacPorts when Homebrew came out. I was amazed how quickly Homebrew spread, given that it did everything worse. I honestly put its popularity down t

by twic 6y ago

I was using MacPorts when Homebrew came out. I was amazed how quickly Homebrew spread, given that it did everything worse. I honestly put its popularity down to it being written in Ruby, which made it the default choice for the large population of Ruby programmers on the Mac.

ericwood 6y ago
maybe I'm misremembering this era but macports required building everything from scratch, whereas homebrew offered pre-built binaries
- sirn 6y ago
  MacPorts binary archives were added back in 2011 across all three architectures at the time (ppc, i386, x86_64). Some packages are still maintained for ppc even today.
  - ericwood 6y ago
    That makes more sense, this memory is from 2009-2010 having to compile GCC and other massive packages.
- lordgilman 6y ago
  As mentioned by the other poster they were both source distributions at first, followed by binaries later. The pain is a bit lost to memory, but even as a long-time MacPorts user I understand why people wanted to switch. If everything has to be built from source you also have to build all your build-time dependencies from source, even weird ones for building docs or whatever. The behavior of MacPorts then (and still unchanged today) is to upgrade to the latest versions of all dependencies when installing or upgrading a requested package. So even if you had zlib sitting around if an update was pushed to zlib you're going to be building a new one. A lot of packages were forced to autoreconf because the Mac was still gaining popularity and a lot of source distributions didn't have ./configure scripts that supported this or that Mac-specific or MacPorts-specific functionality. So now you have to download and install whatever autotools you need to do autoreconf. And of course MacPorts ships a separate package for autoconf 1.3, 1.4, 1.5, and individual packages can depend on specific major versions of autoconf, so even if you had an up-to-date autoconf 1.4 you're still getting an upgrade to autoconf 1.3 if your package happened to ask for it. It was ugly. Homebrew's initial insistence on requiring the re-use of system packages cut down on flexibility (you can't get a new zlib, you have to wait for Apple to ship one) but greased a lot of wheels people did care about. But as time has gone by both systems have improved on their faults and are in a better place than before. This particular bug sucks for the people affected but I think that the Homebrew people will eventually figure this one out, even if it means making their system more MacPorts-like. Like they have been for the past ten years. ;)
gjasny 6y ago
Some years ago I tried submitting some fixes for MacPorts. It usually took a long time before they were picked up. When I did the same for some homebrew formula I got a response a few hours later. For me homebrew has a much more responsive community and due to their use of Github also a lower bar for contributions. Both might add to homebrew popularity.
- twic 6y ago
  That's fair. I did submit a new package to MacPorts once, and it was a rather arduous process.
- l2dy 6y ago
  Disclaimer: I'm a MacPorts committer. MacPorts uses GitHub too now. We maintain much more ports than Homebrew, and few of our committers have time to regularly go through the PR queue, so our community seems inactive. But actually, we just need more hands on PR management. One important distinction is that most active ports in MacPorts have specific maintainers, and we usually put off merging PRs until the port maintainer approves. With more than 20,000 ports, it hard for the committers to test every change thoroughly, so we rely on our port maintainers to resolve issues and review complex PRs whenever possible. In Homebrew, any maintainer could review and merge a PR instantly, combined with fewer ports to maintain, average time to merge would be much shorter.

by twic 6y ago

ericwood 6y ago

maybe I'm misremembering this era but macports required building everything from scratch, whereas homebrew offered pre-built binaries

sirn 6y ago
MacPorts binary archives were added back in 2011 across all three architectures at the time (ppc, i386, x86_64). Some packages are still maintained for ppc even today.
- ericwood 6y ago
  That makes more sense, this memory is from 2009-2010 having to compile GCC and other massive packages.
lordgilman 6y ago
As mentioned by the other poster they were both source distributions at first, followed by binaries later. The pain is a bit lost to memory, but even as a long-time MacPorts user I understand why people wanted to switch. If everything has to be built from source you also have to build all your build-time dependencies from source, even weird ones for building docs or whatever. The behavior of MacPorts then (and still unchanged today) is to upgrade to the latest versions of all dependencies when installing or upgrading a requested package. So even if you had zlib sitting around if an update was pushed to zlib you're going to be building a new one. A lot of packages were forced to autoreconf because the Mac was still gaining popularity and a lot of source distributions didn't have ./configure scripts that supported this or that Mac-specific or MacPorts-specific functionality. So now you have to download and install whatever autotools you need to do autoreconf. And of course MacPorts ships a separate package for autoconf 1.3, 1.4, 1.5, and individual packages can depend on specific major versions of autoconf, so even if you had an up-to-date autoconf 1.4 you're still getting an upgrade to autoconf 1.3 if your package happened to ask for it. It was ugly. Homebrew's initial insistence on requiring the re-use of system packages cut down on flexibility (you can't get a new zlib, you have to wait for Apple to ship one) but greased a lot of wheels people did care about. But as time has gone by both systems have improved on their faults and are in a better place than before. This particular bug sucks for the people affected but I think that the Homebrew people will eventually figure this one out, even if it means making their system more MacPorts-like. Like they have been for the past ten years. ;)

gjasny 6y ago

Some years ago I tried submitting some fixes for MacPorts. It usually took a long time before they were picked up. When I did the same for some homebrew formula I got a response a few hours later. For me homebrew has a much more responsive community and due to their use of Github also a lower bar for contributions. Both might add to homebrew popularity.

twic 6y ago
That's fair. I did submit a new package to MacPorts once, and it was a rather arduous process.
l2dy 6y ago
Disclaimer: I'm a MacPorts committer. MacPorts uses GitHub too now. We maintain much more ports than Homebrew, and few of our committers have time to regularly go through the PR queue, so our community seems inactive. But actually, we just need more hands on PR management. One important distinction is that most active ports in MacPorts have specific maintainers, and we usually put off merging PRs until the port maintainer approves. With more than 20,000 ports, it hard for the committers to test every change thoroughly, so we rely on our port maintainers to resolve issues and review complex PRs whenever possible. In Homebrew, any maintainer could review and merge a PR instantly, combined with fewer ports to maintain, average time to merge would be much shorter.