Gentoo Ruby Project
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,
and RSpec, to name a few.
|Hans de Graaff
|Robin H. Johnson
All developers can be reached by e-mail using email@example.com.
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
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.
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.
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 http://www.rubyenterpriseedition.com/.
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 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.
We are currently looking for users interested in helping the project with
one or more jobs.
To learn more, visit the Staffing Needs page.
The tasks of the
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.
||Package Ruby 1.9
||Create new eclasses
||Have a working way to switch default symlinks. Done with eselect-ruby.
||Verify USE_RUBY status for all packages in the tree
Resources offered by the
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
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.
Version bumps for existing packages
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