4 ms·

Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in

by sirn 6y ago

Those were one of the reasons, but I believe the biggest reason was MacPorts didn't install from binary archive and requires building everything from source in its early days (in the old BSD port tradition). Binary archives were added to MacPorts in 2011 with MacPorts 2.0, but a lot of people (me included) has already moved to Homebrew, leaving MacPorts with an impression of old, slow, and make your Mac fry an egg. MacPorts these days behaves similar to Homebrew by installing from binary archives by default and only build from source when binary archive is not available. This vastly improved the experience, but the old impression remains for those who got burned (literally for some) by MacPorts. 10 years is a long time, and MacPorts has improved a lot since then.

kitsunesoba 6y ago
The other downside to MacPorts' original way of building everything is that sometimes, for whatever reason, things just wouldn't build and getting help with that was thorny, particularly for those who'd just started dabbling in software development or CLI usage. Where a vet or moderately seasoned user might find the thrown error actionable, the new user would google the error, find a couple of semi-related but ultimately unhelpful archived mailing list threads from n years ago, and probably give up and find some other way to get the package they need.
- todd8 6y ago
  Just today my new config for Emacs refused to build libgit. I could see the CMake error, but rather than figuring out how to fix it I just commented out that part of my config (resulting in slightly more overhead in magic). Even with many years of serious software development, I really don't like debugging build problems. I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.
Wowfunhappy 6y ago
MacPorts does also still drop to compiling from source more often than Homebrew. But that’s mostly because they take a more conservative legal approach towards the GPL—for instance, they won't distribute binaries of any GPL software that links with OpenSSL. Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparison. (As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)
- weaksauce 6y ago
  > Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair point of comparison. On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.
  - deleted 6y ago
    [deleted]
  - saagarjha 6y ago
    I'm surprised it still works, to be honest–Homebrew is usually fairly aggressive about dropping support for older systems.
    - Hackbraten 6y ago
      We don’t support any scenario where things are built from source (i. e. we won’t help you if things break) so technically support has indeed been dropped.
      - weaksauce 6y ago
        Is there no way to enable downloads of builds in homebrew on those systems with the caveat that perhaps it'd have to go back to compiling if there aren't any?
        Hackbraten 6y ago
        The bottles no longer exist. The nodes that used to build High Sierra bottles have been re-commissioned to build Big Sur bottles.
pjmlp 6y ago
This is one reason why using Rust crates in cargo's current form irritates me, if I wanted that kind of experience I would be using Gentoo as daily driver. All the other languages I use support binary libraries on their package managers.
stephenr 6y ago
This is a weird take. Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).
- sirn 6y ago
  Ah, you're right. Now thinking back, I think it was how Homebrew reuse system libraries that make it a better experience than MacPorts at the time since it could cut over half of the building time (it prevent the situation where `port install sl` ended up having to build the entire gcc toolchain). This was actually why "reuse system library" were such a big deal back then. Bottle come much later than that.

by sirn 6y ago

kitsunesoba 6y ago

The other downside to MacPorts' original way of building everything is that sometimes, for whatever reason, things just wouldn't build and getting help with that was thorny, particularly for those who'd just started dabbling in software development or CLI usage. Where a vet or moderately seasoned user might find the thrown error actionable, the new user would google the error, find a couple of semi-related but ultimately unhelpful archived mailing list threads from n years ago, and probably give up and find some other way to get the package they need.

todd8 6y ago
Just today my new config for Emacs refused to build libgit. I could see the CMake error, but rather than figuring out how to fix it I just commented out that part of my config (resulting in slightly more overhead in magic). Even with many years of serious software development, I really don't like debugging build problems. I used to use Fink and MacPorts for MacOS package management, but brew was so easy to use that it won me over.

Wowfunhappy 6y ago

MacPorts does also still drop to compiling from source more often than Homebrew. But that’s mostly because they take a more conservative legal approach towards the GPL—for instance, they won't distribute binaries of any GPL software that links with OpenSSL. Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair comparison. (As an aside, MacPorts must have the most incredible legacy support of any Mac project, ever. They had ARM working within a week of the M1’s release, largely because all of the infrastructure for multi-arch was already in place—to support users on PowerPC!)

weaksauce 6y ago
> Also, ports for older/ancient versions of OS X are frequently source-only, but since Homebrew doesn’t support such systems at all, it's not really a fair point of comparison. On an old, unsupported, system homebrew drops down to compiling. just the other day it compiled for four hours just to update one program. kinda infuriating really since there are downloads for those packages still.
- deleted 6y ago
  [deleted]
- saagarjha 6y ago
  I'm surprised it still works, to be honest–Homebrew is usually fairly aggressive about dropping support for older systems.
  - Hackbraten 6y ago
    We don’t support any scenario where things are built from source (i. e. we won’t help you if things break) so technically support has indeed been dropped.
    - weaksauce 6y ago
      Is there no way to enable downloads of builds in homebrew on those systems with the caveat that perhaps it'd have to go back to compiling if there aren't any?
      - Hackbraten 6y ago
        The bottles no longer exist. The nodes that used to build High Sierra bottles have been re-commissioned to build Big Sur bottles.

pjmlp 6y ago

This is one reason why using Rust crates in cargo's current form irritates me, if I wanted that kind of experience I would be using Gentoo as daily driver. All the other languages I use support binary libraries on their package managers.

stephenr 6y ago

This is a weird take. Homebrew not only installed from source for a long time, when they implemented installing prebuilt binaries, they half-assed the dependency resolution of it, so the binary version of a package would always end up requiring the binary version of the first of any alternate dependencies (ie if A requires B or C, binary pkg A will always require binary package B, and won’t accept C).

sirn 6y ago
Ah, you're right. Now thinking back, I think it was how Homebrew reuse system libraries that make it a better experience than MacPorts at the time since it could cut over half of the building time (it prevent the situation where `port install sl` ended up having to build the entire gcc toolchain). This was actually why "reuse system library" were such a big deal back then. Bottle come much later than that.