Issues with current packaging to get Ruby web apps working

Rubygems

Gem is essentially a source packaging system for Ruby with an 'on-demand' dependency based installer. It's very agile, allows you to maintain multiple versions of software on the same machine and generally is a right pain for packagers to deal with. However users love it.

Essentially there is no effective integration between apt and gem. Rails is entirely gem based and anybody using it will be using Rubygems extensively.

1. The standard rubygems package doesn't place gem installed binaries on the path by default. The package installs binary wrappers into /var/lib/gems/1.x/bin which is obviously not on the path initially. The Debian README suggests that the user should alter their path to include the location of the binaries. Users however don't bother - they just install gems from source, which will create binaries in /usr/bin for them.
2. Apt packages that are also gems don't tell the Gem database that they are in place. And so gem will pull in dependencies that are actually already installed via apt.
3. Ruby1.9 and Ruby1.8 need to have their own copies of binary gems (such as mongrel, ferret, etc.) as they have differing memory layouts. The rubygem package, to its credit, does create separate images in separate areas. However again the binaries are stored in separate areas and are not on the path by default. The presence of multiple interpreters means that the simple solution of just sticking the binaries in /usr/local/bin doesn't really work. Gem1.8 install, followed by Gem1.9 install and a Gem1.8 uninstall would leave you with a broken binary.

Bug here: https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267

Ruby interpreter

The current standard version of Ruby is known as the MRI version 1.8.7 (in Intrepid). This is the version supported by Rails 2.1 and above.

There are however a number of Ruby interpreters coming down the line - Ruby1.9, Rubinus and Jruby. People are starting to test Rails on all of these and no doubt they will expect support in future Ubuntu versions.

Additionally there is a garbage collector patch to 1.8.x that improves the memory efficiency of Ruby and Rails applications under Passenger. Phusion have called this Ruby Enterprise Edition ( http://www.rubyenterpriseedition.com/faq.html ), but I wonder if it should be merged into the mainline.

Rails package

The standard Rails package is not really usable in a production environment.

1. It is monolithic, whereas Rails is modular composing of five or six individual gems depending upon the version. Other gems depend on the internal modules of Rails and gem will pull those in causing mild chaos.
2. It wraps the binary for some reason. This means that the 'rails' command doesn't behave in the way users expect, so they remove the package and install from gems directly.
3. It doesn't integrate with Rubygems - in common with all apt packages.
4. It strips a lot of the internal 'vendored' libraries and replaces them with the Debian packaged versions. This means that the Rails package doesn't quite behave as the Gem version would. Not necessarily a bad thing, but may cause versioning problems.
5. The packaging seems to modify in situ rather than using a patch system making it more difficult to change the packaging.

Options

Rails users expect to have gems available and for them to behave as expected. If they don't get that they just install Rails via gems - compiling as they go. If you search Internet you'll see that overwhelmingly users install Rails on Ubuntu via gems.

The packaging system has to deliver what users expect to see as well as trying to keep in line with policy.

The major problems are definitely the Rubygems package not making binaries available on the path and a lack of Debian apt packages informing Rubygems that they have installed libraries also available via gem. At a minimum those need to be in place to make the Rails system behave as expected.