6 ms·

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

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