gem2rpm

What is it?

gem2rpm is a simple utility that transforms rubygems GEM format packages into the equivalent RPM packages.

Why write gem2rpm?

I manage several Linux-based servers and I already spent time making sure that the machines have a local update server, automatically get updates, are monitored, etc. The whole system uses yum and rpm to do its work. I distribute my own software to these machines as rpms.

The problem I had was specifying dependencies between non-ruby and ruby software. If I had a tool that required rake to build it, there was no way to encode that in the RPM spec file. With gems installed via gem2rpm the dependencies can once again be fully specified in rpms.

Where do I get it?

Easy:

1. Download the gem2rpm script.
2. Unpack with gzip, e.g. gzip -d gem2rpm.gz.
3. Make the script executable, e.g. chmod 755 gem2rpm.
4. Put the script in /usr/local/bin or your personal bin directory.

Version History

0.3 -- 2006-11-04

Add several command-line switches:

• -bb, -bs, -ba: build binary, source, and all rpms just like rpmbuild, based on a patch from Trevor Elliott.
• -O dir: copy built rpms into the given directory.

Available as source, gem, and rpm.

0.2.1 -- 2006-07-05

First useful release.

Available as source and gem.

Usage

Once you're set up, do gem2rpm your-gem-file-here.gem. This will build an RPM that does mostly what you want.

Inital Setup

To get set up, you'll need an RPM build tree. If you're running a recent Fedora Core release, you can create $HOME/rpmbuild like so:

sudo yum install fedora-rpmdevtools
fedora-buildrpmtree

Otherwise you can build as root (not recommended) or read up about how to set up a non-root rpm build tree. The simplest way to do this is like so:

mkdir $HOME/rpmbuild
cp -r /usr/src/redhat/* $HOME/rpmbuild
echo "%_topdir %(echo $HOME)/rpmbuild" >> $HOME/.rpmmacros

Bootstrapping, or How do I manage everything via rpms?

gem2rpm normally requires rubygems to function. This creates a chicken and egg problem. gem2rpm includes code to make an rpm from rubygems, which is not normally distributed as a gem. To bootstrap the system, assuming you have an rpm build tree in $HOME/rpmbuild, do:

1. Get gem2rpm, as above.
2. Get the latest rubygems distribution tgz file from rubyforge. As of rubygems 0.9.0, that would have been rubygems-0.9.0.tgz.
3. Create an RPM from rubygems-*.tgz, like this:

   gem2rpm -a noarch -g 'System Environment/Base' rubygems-0.9.0.tgz

4. Install the RPM you built:

   sudo rpm -ivh $HOME/rpmbuild/RPMS/noarch/rubygems-0.9.0-1.noarch.rpm

Or if you're impatient, I keep an rpm of rubygems around too (rubygems-0.9.0-1.noarch.rpm). A big thanks go to Jim Weirich for creating such a useful tool.

Limitations

• There are some metadata items that gem does not carry that rpm requires. The two that will halt an RPM build are Group and License. For better or worse, gem2rpm defaults these to "Applications/System", and "Ruby License/GPL", respectively. You can specify different values via the -g and -l command-line options to gem2rpm.
• Changelog output in the rpm is generated as a single entry consisting of text indicating that the gem packager released it, like this one for rake 0.7.1:

  * Sun Apr 02 2006 Jim Weirich  - 0.7.1-1
  - rake release 0.7.1.

  This changelog entry in effect considers gem2rpm to be mere translation of one package format into another. There's no way to specify an ongoing log of changes as a repackager.

Todos/Known Bugs

(In no particular order):

• Automate initial setup and remove external dependencies on things like fedora-buildrpmtree. Do so with a --rpmtree or --setup flag. cpan2rpm does this quite nicely.
• Integrate remote repositories such that you can say gem2rpm package and gem will fetch the gem in the usual way and have gem2rpm build an rpm from it.
• Generated RPM dependencies currently include the rubygems pessimistic version constraint operator. Need gem2rpm to express this correctly according to rubygems own "... drop the final digit of a version, then increment the remaining final digit to get the upper limit version number" logic.
• It should be possible to supply a template spec file which specifies things like architecture, license, group, and/or changelog ahead of time such that the rpms always come out right. It should even be possible to ship a set of spec templates for popular gems as a part of gem2rpm.
• I haven't tried building srpms generated from the spec files gem2rpm generates.
• I'm not currently interpreting the Gem platform or extensions attributes. These should make the -a command-line option redundant.
• I'm not currently interpreting the required_ruby_version to generate the correctly versioned ruby dependency for the package. Currently the dependency is on ruby alone.
• Built rpms should be signed if the required rpm macros are present and gem2rpm is running under a tty.
• Fedora and other groups have a notion of an addon package which have a name in the format of %{parent}-%{child}. Addons are defined as:

  If a new package is considered an "addon" package that enhances or adds a new functionality to an existing Fedora Core or Fedora Extras package without being useful on its own, its name should reflect this fact.

  For perl, you see packages like perl-String-CRC32, which includes the String::CRC32 library. It should be straightforward to determine generate similar package names for ruby libraries, e.g. ruby-activerecord.

  While it's easy to determine if a package includes only library code, it's not easy to figure out if a whether or not a dependency within a dependent package depends on an addon package. For example, looking at activerecord*.gem, it's clear that this is a library and should therefore be called ruby-activerectord*.rpm. It's not clear, when looking at the dependencies for rails that activerecord was a library only. Rubygems only says that rails depends on activerecord.

  There's not a whole lot to be done about this without some kind of global knowledge. For the moment, the gem2rpm package names match the rubygems names rather than the external packagers' standards.

Contact Gil <gil (at) fooplanet (dot) com> with comments, feedback, patches, or suggestions.