Archive:PackagingDrafts/RubyGems
From FedoraProject
It is now contained in the Ruby guidelines
Contents |
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
- Packages that contain Ruby Gems must be called
rubygem-%{gemname}wheregemnameis the name from the Gem's specification. - The
Sourceof 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
Requiresand aBuildRequiresonrubygems - The package must provide
rubygem(%{gemname})wheregemnameis the name from the Gem's specification. For every dependency on a Gem namedgemdep, the package must contain aRequiresonrubygem(%{gemdep})with the same version constraints as the Gem - The
%prepand%buildsections of the specfile should be empty. - The Gem must be installed into
%{gemdir}defined as
%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}
- The package must own the following files and directories:
%{gemdir}/gems/%{gemname}-%{version}/
%{gemdir}/cache/%{gemname}-%{version}.gem
%{gemdir}/specifications/%{gemname}-%{version}.gemspec
- Architecture-specific content must not be installed into
%{gemdir} - If the Gem only contains pure Ruby code, it must be marked as
BuildArch: noarch. 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%{gemdir}to the%{ruby_sitearch}directory defined in during%install
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 ruby-%{gemname} must be created in the rubygem-%{gemname} package such that
- The subpackage must require
rubygem(%gemname) = %version - The subpackage must provide
ruby(LIBRARY) = %versionwhere LIBRARY is the same name used in - All the toplevel library files of the Gem must be symlinked into
ruby_sitelib. - The subpackage must own these symbolic links.
As an example, for activesupport, the rubygem-activesupport package would have a subpackge ruby-activesupport:
%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.
