[rabbitmq-discuss] Thoughts from a new user

[Matthew Sackman]

Hi Jon,

On Sat, Sep 18, 2010 at 03:36:03PM -0500, Jon Brisbin wrote:
> +1 on Homebrew over MacPorts. I recently did an upgrade on RabbitMQ in
> MacPorts and it took about 3-4 hours while it compiled an update for
> almost everything I had installed. I only have MacPorts for a few
> utilities. As an example of the difference, here's some stats from du
> on my "/usr/local" vs. "/opt/local":
> 
> +-( ~ ):> sudo du -hs /usr/local
> 359M	/usr/local
> 
> +-( ~/src/erlang ):> sudo du -hs /opt/local
> Password:
> 9.0G	/opt/local
> 
> I want to scream: "are you freaking kidding me!?!?" MacPorts has to
> install over 8.5GB more stuff to support the same amount of software?
> I've almost switched completely away from MacPorts. I'm not installing
> any new software with MacPorts, simply using what's already
> installed.

I certainly want to scream "are you freaking kidding me!?!?" too.

Not many people use Gentoo these days - many of us will remember leaving
our PIIs on over night with them compiling away at KDE or some similar
monster and waking up in the morning to find it's still going. That was
at least 10 years ago. There is absolutely _no_ _way_ I would tolerate a
system where I had to compile every piece of software I needed. I don't
understand why macports or homebrew users do. Having googled around,
macports does seem to support binary packages, but does no one use them?
I run Debian unstable (Sid) on my desktops and laptops, and I apt-get
dist-upgrade most days. That normally results in probably 200MB of
binary package downloads every day in total for maybe 40 updated
packages. Compiling that number of packages every day is clearly
ridiculous.

It seems to me that macports actually gets dependencies much more
accurate to support the _whole_ package than homebrew. For example, yes,
Erlang, in its entirety requires lots of extra stuff to, e.g. build the
documentation. It appears that if you're installing Erlang under
homebrew you're just not going to get that documentation. The same
applies for RabbitMQ itself (there's even a comment in
http://github.com/mxcl/homebrew/blob/master/Library/Formula/rabbitmq.rb
saying that they disable documentation because it has additional compile
time dependencies). Again, distributing binary packages here is the
correct solution: _only_ the package maintainer need have everything
installed to build the documentation, and for the end users, they get it
all, and they don't have to do anything at their end. Runtime
dependencies are frequently a fraction of compile time dependencies.

_I_ am distinctly unhappy about the fact that if homebrew continues to
become more popular, more and more RabbitMQ users are going to be
installing it without the documentation. We put time and effort into the
man pages, and I will _always_ refer to locally installed documentation
in preference to websites: you should always be able to trust that the
locally installed documentation matches the version of the software you
have installed. Some software, in e.g. Ubuntu LTS releases, or Debian
Stable releases, can be 5 years old and no, I would not expect the
authors to clutter their websites with historical records of past
documentation. I would however expect to be able to install the
documentation, if it isn't already, via the package manager, and know
that it matches the version of the software I have installed.

There are other optional dependencies of Erlang, for example X Windows.
This is optional but having it means that you can use some tools (e.g.
appmon) that you otherwise wouldn't be able to use. Macports seems to
assume that you're always going to have X Windows installed somehow,
given how prominantly it's mentioned in
http://guide.macports.org/chunked/installing.html. I can't see any
evidence of X Windows at all looking through the homebrew list at
http://github.com/mxcl/homebrew/tree/master/Library/Formula/. Again, the
correct solution is demonstrated by Linux distributions which for
example have both erlang and erlang-nox packages thus allowing you to
choose which is installed. Then RabbitMQ can depend on erlang |
erlang-nox. In fact, in modern linux distributions, Erlang has been
split up into many smaller packages so that packages really can express
precisely which parts of Erlang they depend on, which bits are
optional, and which bits have no bearing at all on the package.

Over the last 20 years, Linux distributions have honed package managers.
It's no surprise that these days rpm and deb systems are comparable in
power in terms of package management and are extremely capable. _I_ am
frequently amazed at how incapable package management is on other
platforms.

IMHO, most of the pain caused by macports is only addressed by
homebrew's packages _seeming_ to do the absolute minimum required to
make something compile at the cost of excluding (almost?) all optional
features and components.

Matthew