Gem2Rpm

Home | SRPM | gem

This page is obsolete. Please use gem2rpm on rubyforge.

Overview

This package converts ruby gems to rpm's. Because of the differences between the two packaging schemes, it is impossible to come up with a completely automated way of doing the conversion, but the spec files produced by this package should be good enough for most pure-ruby gems. I wouldn't put too much hope into automating the gem->rpm process for gems with binary code such as database drivers. But even for those, Gem2Rpm provides a good starting point for packaging gems as RPM's.

Installation

Download and install the rubygem-gem2rpm RPM from the yum repository or use the gem

Usage

At its simplest, download a gem (let's call that file GEM) and run

gem2spec $GEM

This will print an rpm spec file based on the information contained in the gem's spec file. In general, it is necessary to edit the generated spec file because the gem is missing some important information that is customarily provided in rpm's, most notably the license and the changelog. For Fedora, you will have to correct at least the following fields in the generated spec file:

License

Defaults to "Ruby License/GPL" - check to make sure that that is the case.

Source0

The gem does not contain the full URL to a released version of itself. Make sure that that field lists the complete URL to where the released gem can be downloaded.

Changelog

The generated specfile has a minimal changelog entry, but you will need to fill in your email address.

You can also create source RPM's with gem2spec (by passing -s) — check the output of gem2spec --help for more information

Conventions

A typical source RPM for a gem should consist of three files: the gem file itself, the template for the spec file and the spec file. To ensure that the template will be included in the source RPM, it must be listed as one of the sources in the spec file.

The resulting rpms should follow the naming convention 'ruby-gems-$GEM' where GEM is the name of the packaged gem. The default template also makes sure that the resulting package provides 'ruby($GEM)', according to general packaging conventions for scripting languages.

Gem Limitiations

Owing to its intent as a cross-platform packaging system, Gem has some important limitations that make it next to impossible to fully automate the gem -> rpm conversion process. Amongst them are

• No license field
• No changelog
• No distinction between build and install time (important for gems with binary components)
• Because of its nature as a separate packaging system, gems can not capture dependencies on non-gem system components, e.g., the ruby PostgreSQL driver can not properly describe its build- and runtime-dependencies on the various pieces of the PostgreSQL database

I am very interested in hearing from anybody who has any more insight in overcoming these discrepancies between the two packaging systems.

Template Details

The template is a standard erb file; there are three main variables available in the template file:

• format: The Gem::Format for the gem
• spec: The Gem::Specification for the gem (the same as format.spec)

Maintaining the template with the RPM

Rather than editing the generated specfile, edit the template from which the specfile is generated. This will make it easier to update the RPM when a new version of the Gem becomes available.

To support this process, it is recommended to first save the default template somewhere:

gem2spec -T > ruby-gems-GEM.spec.in

Now, edit the template and then run gem2spec to generate the spec file using the edited template:

gem2spec -t ruby-gems-GEM.spec.in $GEM > ruby-gems-GEM.spec

With that, you can now build your RPM as ususal. When a new version of the gem becomes available, you should edit the saved template and rerun gem2spec over it.