Gentoo Logo

Gentoo Ruby Project


1.  Project Description

The Ruby project maintains packages for Ruby implementations, libraries and development tools.

This project also maintains the RubyGems package, the de facto standard for packaging Ruby projects. Many Ruby packages currently in the Portage tree use this mechanism for installing.

Highlighted packages include Rake, Ruby on Rails, Capistrano, and RSpec, to name a few.

2.  Developers

Developer Nickname Role
Hans de Graaff graaff Lead
Alex Legler a3li Member
Gordon Malm gengor Member
Manuel Rüger mrueg Member
Robin H. Johnson robbat2 Member

All developers can be reached by e-mail using

3.  Supported Ruby implementations


In Gentoo multiple Ruby implementations can co-exist. This is supported through the RUBY_TARGETS mechanism. You can add the RUBY_TARGETS variable to your /etc/make.conf file to select which Ruby implementations you want packages to be installed for on your system. By default only ruby18 is selected.

Code Listing 3.1: /etc/make.conf

# Installs packages for Ruby 1.8 and 1.9.
RUBY_TARGETS="ruby18 ruby19"

Note: Some packages do not support all Ruby targets mentioned below. For example, even if your RUBY_TARGETS setting instructs Portage to install for both Ruby 1.8 and 1.9, but the package only supports 1.8, the package will only be installed for Ruby 1.8. Review the output of emerge -pv <package> to see for which Ruby versions the package is actually installed.

Ruby 1.8.x (aka MRI): ruby18

This version of Ruby is our main implementation. It is available as the 1.8 slot of dev-lang/ruby. It is available in the stable tree, and almost all Ruby packages in the tree are available for this implementation.

Important: Regular maintenance for this version will stop in June 2012. Upstream will continue to provide security fixes until June 2013.

Ruby 1.9.x (aka MRI/YARV): ruby19

This version of Ruby is also stable and available as the 1.9 slot of dev-lang/ruby. This version will become the default ruby implementation for Gentoo after the summer of 2012.

JRuby: jruby

This version of Ruby is based on the Java Virtual Machine. It is available as dev-java/jruby. It is available in the stable tree.

Ruby Enterprise Edition 1.8.x: ree18

This is an enhanced version of Ruby 1.8, featuring various enhancements, most notably in that it requires less memory to run. It is available as dev-lang/ruby-enterprise It is available in the stable tree.

For more information, visit

Important: Upstream has indicated that they will no longer support REE. Instead they suggest to use Ruby 1.9. We will likely mask and later remove REE from Gentoo soonish, but with ample warning time.

Rubinius: rbx

Rubinius is currently available in the unstable tree and should be considered experimental. There are still a few packaging bugs that keep it from being used more widely.

4.  Recruitment

We are currently looking for users interested in helping the project with one or more jobs.

To learn more, visit the Staffing Needs page.

5.  Project tasks

The tasks of the Ruby project are:

Ruby 1.9 - Support for all Ruby packages with 1.9

Ruby 1.9.1 is going to be the first stable release of Ruby 1.9, to be released in January 2009. Our infrastructure is currently being updated, so we should have ebuilds in the near future.

Starting date: 12-29-2007
Milestone # ETA Description
1 Finished Package Ruby 1.9
2 Finished Create new eclasses
3 Finished Have a working way to switch default symlinks. Done with eselect-ruby.
4 Verify USE_RUBY status for all packages in the tree

6.  Resources

Resources offered by the Ruby project are:

7.  Policy for adding new Ruby packages


The ruby herd gets a fair amount of requests to add new packages to the dev-ruby category in Portage. Unfortunately we often get a bit defensive about this and the package requests just hang about. This policy tries to outline our thinking on when to add new packages and what you can do to enhance the chances of adding a new package.

Which packages should go to dev-ruby?

The dev-ruby category should only contain the following packages:

  • Library code (e.g. dev-ruby/mime-types)
  • Packages specific to the Ruby environment (e.g. dev-ruby/rake)

Specifically, applications written in Ruby should not go to the dev-ruby category by default, and they would not normally be maintained by the ruby herd. For example, recently cucumber has been added to the dev-util category, even though it is written in Ruby and started out as a spin of from the more Ruby-specific rspec. However, it now also has support for Java and it provides an application, so it is much better suited for a more targeted category of dev-util.

For libraries and supporting code we tend to add these packages only when they are a requirement for an application that gets added to Gentoo, or a new requirement of said application.

Other packages only get added when there is sufficient demand. We determine this by looking at the number of votes for a package, so feel free to open a bug for it and lobby a few folks to add their votes.

Why not add more packages?

Having this policy may seem silly. Why not just add new packages as people provide ebuilds for them?

In part we are reluctant to add many packages because they should really fall under the responsibility of someone else. For example, sup, the ruby mail client, fits much better to the net-mail herd. After all, not all packages written in C are part of the (not even existing) c herd.

In part we are also reluctant because once a package is added it will increase our workload towards the future. Version bumps, security issues, and QA within Gentoo must be kept up to date. On top of that ruby has a bit of a reputation for code that sees a few frantic releases and is than for all intents and purposes abandoned. Having packages like that in the tree adds disproportionally to our maintenance and takes away from providing you with an overall good ruby experience on Gentoo.

8.  Version bumps for existing packages

gems-based packages

We automatically track updates to gems-based ruby packages, so please don't file bugs for these at all. (Note that the list in question is generated on-demand manually, so it may appear to be out of date.)

If a gems-based package has not been updated to the latest version for some time then this usually means there are issues with it. In that case the best way to help us is to report a bug that includes a fully tested version of an ebuild. The ebuild should work correctly with FEATURES=test and USE=doc on all the ruby implementations that the ebuild supports.

Other ruby packages

For other ruby packages we don't have a centralized mechanism to track new versions, but we still track a fair amount of them by other means. If you find such a package that has not been updated for a month then please feel free to file a bug for it since we may not be actively monitoring it. Please double-check that it is not (also) distributed as a gem to avoid unnecessary bugs.


Page updated 02 May 2010

Summary: This project provides support for the Ruby programming language.

Joshua Nichols
Original author

Hans de Graaff

Alex Legler

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.