Archive:PackagingDrafts/RubyGems

= Packaging Ruby Gems =

Ruby Gems are Ruby's own packaging format. Most Ruby libraries and tools are distributed as Gems, and it is often not straightforward to package Gems as normal RPM's. Gems also contain a lot of the same metadata that RPM's need, making fairly smooth interoperation between RPM and Gems possible. This guideline ensures that Gems are packaged as RPM's in a way that ensures (1) that such RPM's fit cleanly with the rest of the distribution and (2) make it possible for the end user to satisfy dependencies of a Gem by installing the appropriate RPM-packaged Gem.

Both RPM's and Gems use similar terminology --- there's specfiles, package names, dependencies etc. for both. To keep confusion to a minimum, whenever the term from the Gem world is meant, it is explicitly called the 'Gem specification'. An unqualified 'package' in the following always means an RPM.

Guideline
%define gemdir %(ruby -rubygems -e 'puts Gem::dir' 2>/dev/null) The install should be performed with the command gem install --local --install-dir %{buildroot}%{gemdir} --force %{SOURCE0} %{gemdir}/gems/%{gemname}-%{version}/ %{gemdir}/cache/%{gemname}-%{version}.gem %{gemdir}/specifications/%{gemname}-%{version}.gemspec
 * Packages that contain Ruby Gems must be called  where   is the name from the Gem's specification.
 * The  of the package must be the full URL to the released Gem archive; the version of the package must be the Gem's version
 * The package must have a  and a   on
 * The package must provide  where   is the name from the Gem's specification. For every dependency on a Gem named , the package must contain a   on   with the same version constraints as the Gem
 * The  and   sections of the specfile should be empty.
 * The Gem must be installed into  defined as
 * The package must own the following files and directories:
 * Architecture-specific content must not be installed into
 * If the Gem only contains pure Ruby code, it must be marked as . If the Gem contains binary content (e.g., for a database driver), it must be marked as architecture specific, and all architecture specific content must be moved from the   to the   directory defined in    during

Packaging for Gem and non-Gem use
If the same Ruby library is to be packaged for use as a Gem and as a straight Ruby library without Gem support, it must be packaged as a Gem first. To make it available to code that does not use Ruby Gems, a subpackage called  must be created in the   package such that


 * The subpackage must require
 * The subpackage must provide  where LIBRARY is the same name used in
 * All the toplevel library files of the Gem must be symlinked into.
 * The subpackage must own these symbolic links.

As an example, for, the   package would have a subpackge  : %package -n ruby-activesupport ... Requires: rubygem(activesupport) = %version Provides: ruby(active_support) = %version # The underscore is intentional, not a typo ... %files -n ruby-activesupport %{ruby_sitelib}/active_support %{ruby_sitelib}/active_support.rb

Tips for Packagers
Gems carry a lot of metadata; Gem2Spec is a tool to generate an initial specfile and/or source RPM from a Gem. The generated specfile still needs some hand-editing, but conforms to 90% with this guideline.