Hacker News Reader

Comment by bad_user | Hacker News Reader

    3) g++? that's not in homebrew...

He probably meant GCC, which does have recipes in Homebrew.

    Homebrew started taking off, and in 
    my case Just Works

This is the first time I ever heard anyone saying it.

In general Homebrew did a good job for me, but it did break on me a couple of times. And when it did, fixing it caused me a lot of stress, because in the end it's really not much better than "./configure && make && sudo make install".

What I don't understand is how come we can't have binary repositories, like Debian's. Certainly Debian has to handle much more architectures and the number of packages contained is really huge. So how come there isn't such an alternative for Mac OS X? Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?

View on HN

    Homebrew started taking off, and in 
    my case Just Works

This is the first time I ever heard anyone saying it.

Here's another: it worked for me perfectly, in and of itself. I use pianobar, which frequently updates (due to Pandora changing protocol or keys), and I often have to do some recipe editing to get that latest update, but it seemed simple enough. Since the brew update list doesn't get fixes anything like as fast as the pianobar author updates when something breaks, it seems to me that having to wait for someone to actually compile pianobar elsewhere would mean that I'd have to wait days for the packaged version.

If you are attached to binary packages, there's always fink which might even predate Macports.

Unfortunately, building the packages and then keeping them current takes quite a bit of infrastructure which is why fink's binary packages are really outdated at times.

The other issue is with runtime-dependencies: Self-compiling packages gives you the freedom to, say, build vim without X11 support. With binary packages, the maintainer (or the packaging system) must create n packages for n possible combinations (if the project doesn't have some dynamic-library based plugin system) which is, again problematic from a resource-requirement perspective.

That being said, if debian can do it for around 30,000 packages on almost as many architectures as OSX has mere hardware models, why can't OSX do it? With all the app stores and cloud services, Apple is big on 'quite a bit of infrastructure'.

Because Apple don't provide these package management tools, volunteering third-parties do.

Apple are never going to provide Linux-style package management tools because the market for them is minuscule compared to Apple's real market: normal people. For normal people, there's the App Store.

while I agree, the point is moot as this talks about developers. So yes, apple did not make a package management tool. That pisses developers off. Makes no difference because you suck it up if you want to develop for mac/ios.

Its kind of like developing on windows, for windows, gota do what u gotta do.

It may not have started out that way (but it may have, I'm not sure), but MacPorts is an Apple hosted project: http://www.macosforge.org/

What they don't host is the source or compiled versions of any of the packages in the MacPorts repository - potentially for the same reason they include no GPLv3 software in their OS.

It would be perfectly safe for Apple to offer the resources required by the MacPorts project to function adequately.

In some cases, they do. This is especially apparent if you're still using MacPort with PPC, as most of the packages it pulls down are form the MacPorts servers.

Developers aren't "normal people" then? If that's seriously the attitude Apple takes towards its developer community ("no, we won't give you the software you need, get it from the crappy community projects") then why do you put up with it?

It seems like the OP's point is pretty valid to me. I use an OS that gives me what I need to do my job.

> Developers aren't "normal people" then?

No. They aren't. Developers have needs far greater than that of your average everyday user. Apple sells a machine that is the best possible for the greatest number of users, and doesn't really cater to niche markets. I don't get what's surprising about this.

Because even developers do "normal people" things. There are a lot of trade offs, but in my experience Apple provides the best middle-of-the-road machines.

Linux and Windows feel like they exist on opposite ends of the spectrum.

You could always try to revive the Arch OS X project (it was 100% functionally working end-to-end) if you want, but it failed in favor of Homebrew for a reason: no one seems to want to assume the cost (both in time and money) of the binary side of things (hosting, building distributable packages, uploading, etc...).

FWIW nowadays MacPorts does install binaries for packages when available. I just did a "port upgrade outdated" a couple days ago and many of the installs were very fast as a binary of the current version was available for my OS.

Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?

So that an OS upgrade, in which Apple tends to include arbitrary upgrades to system libraries (or the Ruby/Python etc version), doesn't break whatever you installed with Homebrew/MacPorts.

gcc and g++ are part of Xcode. That's the reason you have to install Xcode before you can use Homebrew.

Can't say I love the symlinks; however, I use homebrew for convenience, but in most cases it's ./configure --prefix=$HOME/local ...

This rarely fails. When it does, it's user error.

I believe Fink provides binaries.

This is the first time I ever heard anyone saying it.

What do you mean? People are saying that about homebrew all the time. Have you read on blog posts on it?

It just worked for me too, and I have around 20-25 packages installed.

Reply on news.ycombinator.com