[rabbitmq-discuss] Thoughts from a new user

Jason J. W. Williams jasonjwwilliams at gmail.com
Sat Sep 18 23:43:37 BST 2010


I have to echo Matthew's sentiments on MacPorts. I've had pretty good luck with it once I got it tweaked the way I wanted. Also, I only use it to install Erlang when it comes to Rabbit. Rabbit itself I install just by unpacking the generic UNIX tarball into /opt. Fast and simple. Also, by symlinking /opt/rabbitmq-server to /opt/rabbitmq_server-xxxx I can keep multiple versions around for testing. 

I wouldn't be against supporting homebrew but I wouldn't abandon MacPorts to do it. 

Regarding the documentation, I usually find what I need but I'd agree it's not as neatly organized as MongoDB. I do like the design of RabbitMQ.com. 

-J

Sent via iPhone

Is your e-mail Premiere?

On Sep 18, 2010, at 15:52, Matthew Sackman <matthew at rabbitmq.com> wrote:

> 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
> 
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss


More information about the rabbitmq-discuss mailing list