Hacker News new | past | comments | ask | show | jobs | submit login

Macports builds something of a sandbox, which from the users point of view is neither small nor simple.

It is easier for the Macports team to make sense of bug reports with a sandbox, however, which is, I assume, why they do it. It is explicitly the reason they forbid installing to /usr/local.




Macports used to not build this "sandbox", but learned the lesson that relying on Apple as your only source of updates to critical base libraries was fraught with peril: not only do you not get updates you might need ("upgrade to 10.6" is not a reasonable response to someone who just wants to use a project that needs a slightly newer version of libcurl), but sometimes Apple can ship changes that break compatibility without realizing it (as they were not using that part of the library). Once you start dealing with this complexity, the sandbox is actually much /simpler/, as you get well defined results: the only variability are changes in kernel behavior, which tend to be a much less shifty target.


The "sandbox" increases the complexity of the system that the user deals with. The other notion of simplicity is one that should matter only to the Macports developers.

I do not like to criticise open-source projects, but the (reasonably polite) hostility that stating this simple fact has attracted does make me think that the supporters of Macports have stopped seeing things from the user's point of view.

If you want a packaging system whose job is to protect you from the risk of certain rare but possibly messy mishaps, then Macports might well be what you want. I recommend being less risk averse, and use a mixture of Homebrew and installing to /usr/local. It will cost some research and reinstall time now and then, but it will result in a system that is easier to get an overview on.

The talk I have seen of "destroying" one's system installing via Homebrew is pure FUD, and I do not know what lies behind it.


As a user, I find knowing that "install X from MacPorts" should always work, no matter what underlying version of Mac OS X I have, can always be up to date with the latest features, without having to update Mac OS X, and won't fail when I /do/ want to upgrade Mac OS X, the definition of "simplicity".

(Honestly: what does Homebrew make simpler than MacPorts anyway? Near as I can tell, the only reason people seem to like it is that it doesn't take as long to compile software, which argues more strongly to me that we need binary distributions that can download pre-compiled copies than that we should attempt to use the libraries to save installation time.)


Why I prefer Homebrew:

1. No alternative copies of Python, Perl, Ruby, zlib, etc...

2. Everything installs to where it is supposed to, i.e., under /usr/local/

After installing via Homebrew, things do not look drastically different to having compiled them by hand.

Fink does install precompiled binaries: http://www.finkproject.org/

If you think there is no complexity issue with sandboxes, try using both Macports and Fink side-by-side.


1. No alternative copies of Python, Perl, Ruby, zlib, etc...

And if I need a newer version of Python, coupled with a dependency tree of third-party modules?

I don't see why this matters, other than some pedantic sense of cleanliness ("NO DUPLICATES!" ... even though they're not, in reality, duplicates).

2. Everything installs to where it is supposed to, i.e., under /usr/local/

You can configure MacPorts to do this, but the reason it's not the default was to leave /usr/local for the user's own manually installed software. I don't think this really matters either way.

After installing via Homebrew, things do not look drastically different to having compiled them by hand.

I don't know what this means or why it matters.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: