RPM Package a ruby project

Question

I want to package a ruby program that I get from git into a RPM package. I have at my disposition a build server and a production server (Same OS / Same Arch).

As most ruby project, mine does have gem dependencies.

I found two ways of doing what I want and I would like to know which is the best - most unix/linux philosophy - operations wise

• Bundle less on the production server

The first one (which looks the better to me) is to do a bundle install --standalone --deployment --path %{buildroot}/usr/lib/rubygems/1.8/gems/ --binstubs %{buildroot}/usr/lib/rubygems/1.8.bin. This will install the gem on the gem system path on the server where the .rpm will be deployed, no need to install bundle. Where I am unsure, is when I will install other rpm with the same gems what will happen ? What happened when I remove a package with a gem that was shared between two packages ?

• With bundle on the production server

The bundle install --deployment command would take place directly in the project itself. This way everything can be found on the vendor/ directory. Online I could see some post about the vendor-everything policy, it just doesn't seem right operations wise, since lots of gem will be duplicated. Since I do not have a ruby background I don't know the exact pros/cons it can have

If some one has already made something similar, which way have you take ? What - operations wise - is the best take on this ?

Answer 1

Don't deploy a gem with RPM unless you deploy all of its dependent gems with RPM as well. See the Fedora Packaging Guidelines for Ruby for information on the correct way to build an RPM and a sample spec file for building gems, as well as how to build an RPM for your Rails web app.

If you need to do something that breaks RPM best practices, then you're better off to not use RPM to deploy. Use deployment-focused tools such as capistrano instead; it can automatically checkout your app from git and deploy it correctly (once you configure it).