[rabbitmq-discuss] Debian Packaging for additional components

Michael Klishin michael.s.klishin at gmail.com
Tue Jul 12 20:42:49 BST 2011

2011/7/12 Matthias Radestock <matthias at rabbitmq.com>

> From a rabbit user perspective, I reckon by far the most convenient way to
> get hold of rabbit plug-ins is not having to get hold of them at all :) I.e.
> we could bundle plug-ins with the server, and add a mechanism (in, e.g.
> rabbitmqctl) to select which plug-ins should be enabled.
> But there are downsides too. The main one is that bundling only works for
> plug-ins blessed by Rabbit HQ, with all other plug-ins having to go the
> existing .ez route. And there are some challenges in the packaging, e.g.
> what should the source distribution (i.e. the source downloads on the rabbit
> web site, the debian source package, etc) contain?
> Suggestions are welcome on how we should go about this.


bundling "RabbitMQ HQ" plugins and having a way to activate them sounds like
a good idea. 3rd party plugins can work the way they work today, and the
source distribution should then include plugins, structured similarly to the
way RabbitMQ public umbrella repository is structured. I don't think it will
make building packages significantly more complicated.

Some package managers, for example, Homebrew, push back on adding ways to
install plugins for projects like RabbitMQ and Nginx (the idea is that it is
too much work for everyone to maintain packages that in turn manage
"subpackages"). But if plugins are part of the core RabbitMQ package and
only need activation, this issue will likely to be considered resolved for
Rabbit once and for all.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20110712/4c345d7a/attachment.htm>

More information about the rabbitmq-discuss mailing list