Debian packaging of rubygems

Notes on running rubygems as debian packages.

The Problem

  1. gems are needed: Recently, gems have become necessary for ruby programming. More and more ruby code requires the gem ability to include a particular version (or range of versions) of a ruby library.
  2. gems are limited: However, gems pose a problem for system maintenance. There is no way to just apply security fix updates, for example. Also, most sysadmin automation tools work well with debs, but not at all with gems. Although this argument is overblown, it is true that some gem authors are less than diligent about incrementing the major version number when the API is no longer backwards compatible.
  3. debs have problems: The ruby libraries packaged in debian are very limited in number, are only for a single version of the library, and don’t install as gems, so code that requires gems won’t work. To package ruby libraries in a way that installed gems would violate debian guidelines.

The difficulties with ruby and debian are compounded by a long history of bad blood between the ruby packaging team in debian and ruby folks. Many unkind words have been said in both directions. The problem is that both sides are right, but each refuses to budge: gems are both necessary for programmers and unworkable for sysadmins.

A Humble Solution

  1. Create .deb packages that install as .gem packages. These packages should not be named libX-ruby, but rather rubygem-X, or something, to avoid name collisions with existing packages.
  2. Create different a .deb package for every different version of a gem and allow these to all be concurrently installed.
  3. Create a registry of gems that following standard API version convention. When a new minor version of these gems are released, the new version replaces the old (unless the old is specifically installed).
  4. Create a registry of gem security fixes. When a new one comes out, the preferred installed package for a version series will change.
  5. Rewrite the rubygems code to support FHS so that packages can install as gems and still follow the FHS.

This is not such an original idea. All these projects attempt to automate the creation of .deb from .gem:

Holy shit! How did we get here? With much difficulty, confusion, and harsh words. The problem, however, is not trivial and will require some work to come up with a solution that can make everyone happy. Hopefully, we can also stop duplicating our efforts. Yes, there really are three different projects called ‘deb2gem’.

Problems with gems

  1. gems are difficult to install if they require compilation, since there is no way to easily tell what headers you need installed in order to compile.
  2. when you uninstall a gem that had many dependencies, those dependencies stick around even if they are no longer needed by any gem.
  3. gems are incredibly slow to install and search. the gem servers seem to be way overloaded all the time, which is a big pain in the ass.

Problems with debs

Because existing debs don’t package ruby libraries as gems, they have these problems:

  1. No way to include a particular version of a library in your code.
  2. breaks if some code is written expecting the library as a gem.