The currently-active branch of Ruby-kit is
2.7-prime, created in early January 2021 by Funtoo, and is based on a snapshot of Gentoo Ruby ebuilds from late December 2020. It is an auto-generated kit which will allow more frequent updates.
At the time
2.7-prime was created, the Gentoo Ruby Team was focusing on integrating support for Ruby 3.0 into Gentoo. Another notable event happening at around this time was the deprecation of Ruby 2.5 by the Ruby team itself, as it is currently in maintenance mode and nearing EOL. These events were factored into the plan for Ruby-kit related to supported versions.
Supported Ruby Versions
The Ruby versions available in
- This is the Funtoo OS "preferred" Ruby for satisfying system dependencies. This is the Ruby version that applications will try to use if 2.7 support is actually available in ebuilds and dependencies.
- This is the Funtoo OS "compatible" Ruby for satisfying system dependencies. This is the version that all applications are likely to support and is more universally supported in ebuilds. 2.6 is also our **backup** version of Ruby that is used by our eclass logic.
- This version of Ruby is being made available but is not currently used for resolving dependencies for Funtoo systems. It can be installed by Ruby developers and Ruby modules can be installed via
2.7-prime has a number of important Funtoo changes which are documented here.
ruby-*.eclass eclasses have been forked and are stored in our
kit-fixups repository, in
core-kit/curated/eclasses, so they will end up on end-user systems inside Core-kit and will be available to all kits.
The forked eclasses are:
The Problem Being Solved
These changes were made to solve a specific issue. We have found that in Gentoo, Ruby versions (this also happens with Python versions) can be very "sticky". By "sticky", I mean that it can be very hard to get rid of an older version of Ruby (or Python), and upstream Gentoo tends to try to handle this by orchestrating a mass purge of all ebuilds that reference this older implementation. Only then can this older version of the language be removed or deprecated in Gentoo. This involves updating hundreds of ebuilds, which is a lot of manual work, and thus isn't really a great solution. But it does fit in with the Gentoo model of having a large development team that "shuffles" individual ebuilds along to either add support for new language versions, or drop old versions. For Funtoo, this isn't really a workable option so a better solution was needed.
For Funtoo, I wanted to have a way to define what versions of Ruby were active in a build of Funtoo, in as central a way as possible, and not have annoying, soul-crushing dependency problems that
users or Funtoo developers had to deal with. The solution used was to modify Ruby eclasses to more aggressively mask the
USE_RUBY settings from the ebuilds based on what Ruby implementation
we actually want "active" in Funtoo.
A specific issue I wanted to address was to be able to easily deprecate Ruby 2.5. And yet, many ebuilds still referenced
ruby25 or even earlier as the maximum version that they support. To fix this issue, I
introduced an idea of a "backup Ruby version" which would get enabled if our more aggressive masking of
USE_RUBY resulted in a Ruby package or module not having support for any Ruby
implementation at all. In this case, the eclass will enable the backup Ruby version -- in this case Ruby 2.6, which has a high degree of compatibility with Ruby 2.5 that we are deprecating so it
is likely to work in the majority of cases for older Ruby ebuilds, and in the few cases where it may not, we can deal with these problems on a case-by-case basis.
This way, we can set Ruby 2.6 as our "baseline", or "compatibility" version that our minimum supported version in Funtoo ebuilds. Ensuring everything works with 2.6 should not be tremendously hard, and we can move to 2.6 without changing every single ebuild that only references a 2.5 or earlier Ruby version.
These masking changes also have an interesting side-effect where we can make Ruby 3.0 available for developers, but Ruby-using packages will not actually depend on Ruby 3.0, even if they reference
USE_RUBY, until we "flip the switch" and tweak our eclasses. This allows Ruby 3.0 to be available to merge but not get entangled in system dependencies. This does mean that you
would need to install Ruby 3.0 dependencies using
gem, which is a fine solution since no ebuilds in Funtoo will need any ruby-module ebuilds installed. Basically we create a clean-room where
Ruby 3.0 can be used for now, until it becomes the official Ruby implementation in a future version of this kit -- when we choose.
The most notable changes are in the following files:
- Aggressively mask
USE_RUBYbased on our
RUBY_TARGETSsettings. If we mask all implementations, add
BACKUP_RUBYas backup implementation (currently 2.6).
_ruby_get_all_impls(), aggressively mask
USE_RUBYebuild settings based on our
BACKUP_RUBYlogic. Also change
IUSEcalculation to not aggressively mask
IUSEsettings, since the ebuild could have some logic based on some of the Ruby targets we masked out, and not having these targets in
IUSEwill cause Portage to complain.
The eclass changes, taken as a whole, allow Funtoo to set the Ruby implementation(s) active
in Funtoo more easily. Traditionally, in Gentoo, Ruby implementations are set based on
RUBY_TARGETS, which is defined in the profiles and set to something like this:
make.defaults(bash source code)
In addition, Ruby-using ebuilds that leverage the Ruby eclasses will set something like this:
ruby-using.ebuild(bash source code)
USE_RUBY="ruby25 ruby26 ruby27 ruby30"
The Funtoo changes cause the
USE_RUBY settings in ebuilds to be more aggressively masked based on the Funtoo OS settings for
RUBY_TARGETS. In addition, if our more aggressive masking causes a Ruby module or package to not have any valid Ruby implementations, a "backup" typically safe Ruby implementation will be enabled automatically.
This gives us the ability to "focus" our Ruby support around specific versions of Ruby.