[rabbitmq-discuss] Debian Packaging for additional components
matthias at rabbitmq.com
Tue Jul 12 20:26:08 BST 2011
On 12/07/11 19:28, Alex Bennee wrote:
> 1. Does anyone already package the plugins as debs?
> 2. If not, is anyone currently working on it?
No, but finding a way to distribute plug-ins that is more convenient for
our users is on our to-do list.
(Un)fortunately rabbit is deployed on many platforms, not just debian.
Until a year or so ago the only way to get hold of plug-ins was to build
them from source from the hg repos. That was a serious barrier for
users. Then we started producing downloadable .ez files. No more
compiling from source and they have the huge advantage of working across
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.
As well as being convenient for users, this "batteries included"
approach is also completely cross-platform. And it addresses another
issue too: some plug-ins, such as management, arguably are part of the
server; the fact that they are plug-ins is a implementation detail. And
I can envisage a future rabbit being refactored s.t. the AMQP support
becomes a plug-in, just like STOMP is today. Would we then ship a server
package that doesn't do anything? That doesn't seem right. Bundling of
plug-ins would avoid that situation.
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.
More information about the rabbitmq-discuss