4 ms·

Not only that, MacPorts also kept all versions installed even after upgrade unless it's explicitly uninstalled (port echo inactive / port uninstall inactive); s

by sirn 6y ago

Not only that, MacPorts also kept all versions installed even after upgrade unless it's explicitly uninstalled (port echo inactive / port uninstall inactive); suffix every binaries with versions by default (e.g. pip-3.8, ansible-3.8) and only linked them as unversioned when explicitly set (port select --set python3 python38) which should be more familiar to people coming from Linux/BSD world. I wish more people try out MacPorts.

hultner 6y ago
How well does macports and home brew play together on the same system these days? I used to use ports back in the days and appreciated it coming from FreeBSD previously but at some point most things I wanted were simply only available in brew, at that time brew and ports didn’t play well together on the same system so sometime around SL/Lion I switched to brew completely.
- l2dy 6y ago
  Default prefix of Homebrew is now /opt/homebrew on macOS on ARM, which should not conflict with MacPorts anymore. For macOS on Intel, MacPorts does not play well with Homebrew because it took /usr/local, so ports built from source might use Homebrew files and break.
  - hultner 6y ago
    I see so as an Intel user I'd better stay away from mac ports if I want to use software only published on brew. I probably won't buy a new computer in the coming 5 years, so arm isn't relevant for me at this moment. But good to know for the future.
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. ;)

by sirn 6y ago

hultner 6y ago

How well does macports and home brew play together on the same system these days? I used to use ports back in the days and appreciated it coming from FreeBSD previously but at some point most things I wanted were simply only available in brew, at that time brew and ports didn’t play well together on the same system so sometime around SL/Lion I switched to brew completely.

l2dy 6y ago
Default prefix of Homebrew is now /opt/homebrew on macOS on ARM, which should not conflict with MacPorts anymore. For macOS on Intel, MacPorts does not play well with Homebrew because it took /usr/local, so ports built from source might use Homebrew files and break.
- hultner 6y ago
  I see so as an Intel user I'd better stay away from mac ports if I want to use software only published on brew. I probably won't buy a new computer in the coming 5 years, so arm isn't relevant for me at this moment. But good to know for the future.

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