[rabbitmq-discuss] Debian Packaging for additional components

[Matthias Radestock]

Alex,

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 
all platforms.

 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.


Regards,

Matthias.