3 ms·

Any idea why the Mac crowd seems to shun binary packages? Before playing with MacPorts I wasn't even aware of the concept of a source-only package manager. Each

Any idea why the Mac crowd seems to shun binary packages? Before playing with MacPorts I wasn't even aware of the concept of a source-only package manager. Each time I spend 20 minutes recompiling the entire xorg dependency chain because the minor version number got bumped from .1 to .2, I cringe at the thought of how many CPU cycles are being wasted all over the world to produce essentially the same thing.

spicyj 17y ago
Simply because there isn't an up-to-date package management system that provides binary packages. Typing "brew install <whatever>" is a million times easier than searching out the software package's website and hunting around for a binary package that's for your OS version.
- blasdel 17y ago
  ...and that works together with all the dependencies you've also installed, and the set of configure --options they were built with. It's also a strong guarantee that if the package is built any different than the upstream default, you know exactly what changes are being made, since they happen on your machine.
jvdh 17y ago
For the last couple of years there have been different CPUs for Macs. First we had the G4, then the G5, followed by the switch to Intel. And even for the Intels there's lots of different subtypes. And of course now with the switch to Snow Leopard we've got the 64-bit issue as well. Yes, it does take a while, but these days it doesn't take that long anymore.
- jcromartie 17y ago
  Yeah, but as of right now you could basically call it PPC/Intel, and most users are probably running Intel. Binaries (universal or not) are good enough for every single application distributed for the Mac platform. Why would command-line tools or libraries need to be any different?
  - blasdel 17y ago
    The majority of these packages link against non-system libraries, and the ones that don't are there to be linked against by other packages. OS X is unique among modern unixes in that absolutely nobody distributes app bundles that have external dependencies on non-system libraries (except for a few that are too freetarded to bundle ffmpeg).
masklinn 17y ago
> Any idea why the Mac crowd seems to shun binary packages? 4 different architectures (PPC/32b, PPC/64, Intel/32 and Intel/64) are probably hell on a binary-only package manager. Source-only is simpler and lighter on the architecture side, though it's much heavier on the client one. Fink does binary packages though, I think.
- there 17y ago
  the openbsd project builds 1700 to 5600 binary packages for each of 12 architectures on a weekly/monthly basis and continuously mirrors them throughout dozens of ftp sites. building a few dozen or even a few hundred packages for 4 architectures isn't that hard, it's just a matter of resources. someone has to have 4 of those machines sitting around doing nothing but building packages, uploading them somewhere, and then take the time to fix ports and dependencies that don't build on certain architectures. fwiw, i use fink on mac os and it supports binary packages. many of the ports in its stable branch are available as binary packages.
mxcl 17y ago
Personally there were two reasons: 1) I don't want bandwidth costs 2) It's much harder to get contribution for a binary system (I expect). If you're installing foo and it doesn't work for some reason you probably won't want to install Xcode and Homebrew-dev in order to try and fix it. When you're installing from source you're already a `brew edit foo && git push` away from helping fix it. It's also worth noting that most packages don't have dependencies in Homebrew. This is because we don't duplicate what is already there and OS X comes with quite a lot of the common low level libraries. So compiling foo takes significantly less time than it does with Macports.

spicyj 17y ago

Simply because there isn't an up-to-date package management system that provides binary packages. Typing "brew install <whatever>" is a million times easier than searching out the software package's website and hunting around for a binary package that's for your OS version.

blasdel 17y ago
...and that works together with all the dependencies you've also installed, and the set of configure --options they were built with. It's also a strong guarantee that if the package is built any different than the upstream default, you know exactly what changes are being made, since they happen on your machine.

jvdh 17y ago

For the last couple of years there have been different CPUs for Macs. First we had the G4, then the G5, followed by the switch to Intel. And even for the Intels there's lots of different subtypes. And of course now with the switch to Snow Leopard we've got the 64-bit issue as well. Yes, it does take a while, but these days it doesn't take that long anymore.

jcromartie 17y ago
Yeah, but as of right now you could basically call it PPC/Intel, and most users are probably running Intel. Binaries (universal or not) are good enough for every single application distributed for the Mac platform. Why would command-line tools or libraries need to be any different?
- blasdel 17y ago
  The majority of these packages link against non-system libraries, and the ones that don't are there to be linked against by other packages. OS X is unique among modern unixes in that absolutely nobody distributes app bundles that have external dependencies on non-system libraries (except for a few that are too freetarded to bundle ffmpeg).

masklinn 17y ago

> Any idea why the Mac crowd seems to shun binary packages? 4 different architectures (PPC/32b, PPC/64, Intel/32 and Intel/64) are probably hell on a binary-only package manager. Source-only is simpler and lighter on the architecture side, though it's much heavier on the client one. Fink does binary packages though, I think.

there 17y ago
the openbsd project builds 1700 to 5600 binary packages for each of 12 architectures on a weekly/monthly basis and continuously mirrors them throughout dozens of ftp sites. building a few dozen or even a few hundred packages for 4 architectures isn't that hard, it's just a matter of resources. someone has to have 4 of those machines sitting around doing nothing but building packages, uploading them somewhere, and then take the time to fix ports and dependencies that don't build on certain architectures. fwiw, i use fink on mac os and it supports binary packages. many of the ports in its stable branch are available as binary packages.

mxcl 17y ago

Personally there were two reasons: 1) I don't want bandwidth costs 2) It's much harder to get contribution for a binary system (I expect). If you're installing foo and it doesn't work for some reason you probably won't want to install Xcode and Homebrew-dev in order to try and fix it. When you're installing from source you're already a `brew edit foo && git push` away from helping fix it. It's also worth noting that most packages don't have dependencies in Homebrew. This is because we don't duplicate what is already there and OS X comes with quite a lot of the common low level libraries. So compiling foo takes significantly less time than it does with Macports.