Since the beginning of 2011, the Debian Ruby team has been working on several big changes. Those changes all are available in Debian unstable, some of them are also available in Debian testing, and they should all be available in the next Debian and Ubuntu releases.

I think that it addresses most of the reasonable concerns about Ruby in Debian.

Using alternatives to switch between Ruby implementations

The alternatives system is now used to manage the “ruby” symlink and the other related symlinks, making it easy to switch between Ruby implementations (only Ruby 1.8 and 1.9.X at the moment) (see this mail for details). The default choice for Ruby is still 1.8, but this change will make it easy for us to make a switch to 1.9.X by default (likely by the release of Debian wheezy).

Installing gems executables to /usr/local/bin

Rubygems (both as a standalone package, and as shipped with Ruby 1.9.X) now install executables to /usr/local/bin. (The other files still get installed under /var, see this mail)

Enabling gem update –system

gem update –system has been re-enabled. Since upgrading rubygems to a version that may not have been properly tested with the rest of the Debian system may cause issues in the user’s system, there’s a big warning about that. The user can confirm and upgrade rubygems anyway by defining an environment variable.

New gem2deb packaging helper

There’s a new packaging helper, named gem2deb, that makes it very easy to generate Debian source packages from Rubygems. We are in the process of migrating all ruby libraries packaged in Debian to that new helper. It will take some time, though (help is welcomed).

One big benefit of the switch to gem2deb for the Ruby community is that, in the process, we are enabling test suites at build time for each package and each Ruby implementation. This should make it easy to detect regressions in new interpreter versions.

Ruby 1.9.3

We will switch to Ruby 1.9.3 ASAP (probably when it is branched off trunk, with a package first in Debian experimental). Since the Ruby compatibility version issue is likely to stay around, we will re-evaluate how we are dealing with it (to avoid the ruby1.9.1 package <=> ruby -v = 1.9.2 problem that confuses many users). This is likely by switching the package name to ruby1.9.3 (keep a ruby1.9.1 package for compatibility). The package containing the shared library will stay libruby1.9.1.

You are the one that know it best, but I think it deserved this little explanation, because this was not obvious, at least to me. The Ruby world has some specificities compared to others such a Python, I think. Thank you for your work and good luck.

A lot of thanks for your entire hard work on this site. Kim delights in doing research and it’s really obvious why. A lot of people learn all of the dynamic manner you render functional solutions through your web blog and as well welcome response from other ones about this article then our daughter is now starting to learn a whole lot. Have fun with the remaining portion of the new year. You’re performing a tremendous job.