Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ

A lot is being said on how Ruby is packaged in Debian and Ubuntu. In this post, I’m trying to go through the most common myths and give my position as a Debian Ruby maintainer. Note that those are my views, not necessarily those of the other Debian Ruby maintainers.

Myth: Ruby is completely outdated in Debian and Ubuntu

There’s a culture in the Ruby community of always using the latest bleeding-edge version. There’s also a culture (though this one has recessed a bit, I think) that it’s perfectly fine to change APIs in incompatible ways if it makes the software slightly better.

In Debian (and Ubuntu) stable releases, we try to provide a rock-solid version of Ruby that won’t be allowed to change API during the support lifetime of a release. Bugfixes for important bugs can be applied, but that’s basically all. So it’s not surprising that Ruby in released versions of Debian and Ubuntu is behind the latest upstream version.

In development branches, we are following the latest upstream versions quite closely. Debian 6.0 ‘squeeze’, to be released by the end of the year, includes Ruby 1.8.7-p302, and will include 1.9.2-p0 (the currently of Ruby 1.9.2 in squeeze is currenty a SVN snapshot from beginning of august).

There are people interested in installing a packaged Ruby that just works, and other people interested in installing their own version of Ruby (through RVM and such). People in the Ruby community tend to forget about the first category, and consider that, because they install Ruby from source or with RVM, that should be the solution for everybody.

We need the Ruby community to respect that different people have different ways of using Ruby, and to stop recommending that everyone using Debian and Ubuntu should install Ruby from source.

We also need to leverage the backports services for both Debian and Ubuntu to provide a way to install the latest upstream version on stable releases. The only reason why we are not doing it yet is lack of time.

Myth: Ruby is split into a myriad of packages in Debian

In the past (pre-2005), a decision was made to split some libraries from the standard library into separate packages. This was motivated by:

  • the size of some libraries, like REXML
  • the fact that some libraries, like OpenSSL, readline, gdbm and tk require other library packages to be installed
  • licensing concerns about shipping some code (a .so) linked with OpenSSL, and some other code (another .so) linked with readline, in the same package.

Most of the split was undone a very long time ago, and the readline and openssl splits were undone this year. The current package in Debian squeeze has:

  • ruby1.8: binaries (ruby itself, irb, rdoc)
  • libruby1.8: the standard library, except ruby-tk
  • libtcltk-ruby1.8: ruby-tk (merging it with libruby1.8 would add several megabytes)
  • ri1.8: contains both the ri binary and documentation
  • ruby1.8-dev: development headers (to build applications or gems linked against the Ruby C API), and statically built version of the library
  • ruby1.8-elisp: Ruby emacs mode
  • ruby1.8-examples: Examples
  • libruby1.8-dbg: debug symbols

It is always possible to merge more packages, but merging any of the other packages would significantly increase the size of what you get by default, and might discourage people to use it in some contexts (disk space is not always cheap. Think embedded systems and smartphones).

Myth: Rubygems is crippled in Debian

There are two differences in the rubygems Debian packages. First, gems are installed in /var/lib/gems, not /usr/local/lib/gems. That is because rubygems are seen as “state” for the Rubygems package, not independant software installed separately. A change for this is currently being discussed, and should be done after the squeeze release. (I don’t think that it’s reasonable to push that change now). A consequence of installing to /var/lib/gems is that gems’ binary are outside of $PATH. After the change, gems’ binary would also be installed in /usr/local/bin.

Second, gem update --sytem is disabled in the Debian package, because that would replace code from the Rubygems Debian package with code downloaded from the Internet, and can break your system in subtle ways. We have changed this (in SVN, not in any package in the archive yet) to allow gem update --system if a specific environment variable is set, which gives us the opportunity to display a warning message.

Myth: Ruby is slow on Debian

Ruby is built with the pthread threading code, because not using it breaks many native Ruby libraries (Ruby-gnome2, for example). And other Linux distributions are doing the same.

There are some very old benchmark results floating around in some blogs that show that the pthread code has a performance impact of about 20%. There are been patches for that for a long time (applied in Ruby Enterprise Edition), but they were never properly sent back. Actually, all the discussions about this issue were rumors and blog posts, and there wasn’t even a bug report about it!

After the bug was reported properly, it was fixed in a timely manner. The fix is not yet included in the Ruby 1.8.7, but is being applied as a patch to the Debian package since (So the Debian package is actually newer and faster than upstream Ruby in that regard).

What makes Ruby so difficult to maintain in Debian?

The main problems we have with Ruby are portability issues. The only officially supported platform for Ruby is IA32 (i386 in Debian), and everything else is best effort. It means that it is not even supported officially on x86_64/amd64! Debian supports a dozen of architectures, and the Ruby package has to work on each of them. Ruby 1.8 is mostly OK nowadays thanks to the help of Debian porters, but we still have serious problems with 1.9.2, since the test suite fails on sparc, hppa, ia64 and Debian GNU/kFreeBSD.

Why doesn’t Ruby use the alternatives system on Debian?

The alternatives system provides a way to switch between different software providing the same functionality. Currently, if you want to use Ruby 1.9.2, you need to use the ruby1.9.1 executable (1.9.1 = ruby compatibility version here). The alternatives system would allow to switch ruby to ruby1.9.1 on a system-wide basis.

However, the situation of applications and libraries working only with Ruby 1.8 should be clarified: those should use /usr/bin/ruby1.8 instead of /usr/bin/ruby. Another problem is that the way to specify packages dependencies still need to be determined. There’s nothing impossible to do about that, it just needs someone to do the work.

Where do we go from here?

The Ruby developers (or expert users) community is generally very hostile towards Debian. Many harsh words and insults are used in discussions mentioning Debian in the ruby-core@ mailing list, and there are frequent recommendations to avoid the Debian packages and install from sources, which is quite demotivating (Actually, what prompted that blog post is someone calling Debian-specific changes unforgivable).

This atmosphere makes it hard to recruit people, and the Debian Ruby teams are completely understaffed, which is clearly the major blocker to improving the situation further. We are 3 co-maintainers for the interpreter packages, and I’m the only Debian Developer that is really active on a regular basis in the pkg-ruby-extras team (that does libraries and applications packaging). We desperately need help, but at the same time I have no time to improve our documentation and make it easier to join the team.

While I haven’t reached a final decision yet, I am also likely to stop doing Ruby work in Debian after squeeze is released, as I am getting increasingly tired and demotivated.

56 thoughts on “Ruby packaging in Debian and Ubuntu: Mythbusting and FAQ

  1. As a Ruby developer and Ubuntu and Debian user, and a system administrator with decades of experience, let me first say that the state of Ruby has improved greatly in recent Ubuntu releases, so thanks for that. But having said that, it’s still not good enough. Just this week I had to rip out the packaged RubyGems and install the real one in order to install Gems successfully, as Brian Candler points out above. I also find it frustrating that I have to mess with symlinks to run 1.9.x as /usr/bin/ruby, but that’s a minor issue.

    The last time there was discussion between the Ruby developers and the Debian maintainers, the Ruby team were keen to work on a solution that would allow Debian to release packages that called RubyGems to update and maintain the Gems. That would have allowed Debian and Ubuntu to release packages for everything, shift the workload of fixing problems to the Ruby developers, and ensure that Ruby was kept up-to-date on Debian and Ubuntu.

    Unfortunately, the attitude of the Debian maintainers was “No, we are not letting RubyGems install code, you do it how we say or else”. At that point, I think most Ruby developers gave up on Debian, and decided they’d just have to download and compile in order to get a working Ruby on Debian. That’s why you see that advice everywhere on the Internet. If you want to change that, you’re going to need to accept that Debian as well as Ruby will need to make changes to how things are done. (While there are legitimate issues with C-based extensions, I still haven’t heard any good reason why we couldn’t fix the other 95% of Gems.)

    The incompatibilities between Ruby versions are exaggerated, in my experience. I switched from 1.8 to 1.9 with very little breakage. The main issue was Unicode vs ‘dumb bytes’, which is hardly Ruby’s fault. My main public library release (RSS and Atom syndication) worked fine once I had fixed that. My personal scripts all kept working too. Maybe there are some ‘clever’ code styles people used in 1.8 that have caused them grief in 1.9, but I haven’t had a problem. I’ve got one production Rails app that’s still running on Ruby 1.8, but that’s because the app isn’t offically supported on 1.9. (As far as I can tell from my own testing it works, it just isn’t officially supported.)

    You also need to distinguish between Ruby and Rails. They are very different communities. Rails developers are Mac-using bleeding-edge “throw it over the wall and let someone else shake the bugs out” types. Many of them don’t believe in such absurd luxuries as API documentation. They tend towards cryptic code and wheel-reinvention. The core Ruby team are a completely different set of people, and are much more pragmatic. They do care about not breaking things and providing an orderly path from 1.8 to 1.9. As a Ruby guy, the Rails community exasperates me.

    Maybe it would be an idea to set up a Google Group or similar discussion list, so people who would like to hash out these problems and come up with a solution can do so? Then the proposed solution could be taken to the Debian and Ruby teams for consideration.

  2. I love debian, but mathew is right. In this case, I think debian is dead wrong.

    The thing that I have never heard debian folks understand is that it is totally necessary to use gems because that is how you bind your code to a specific library.

    It is pointless for debian developers to insult ruby programmers for how fast their APIs change or for incorrectly versioning their APIs. Even if every gem was 100% correctly versioned, the stark reality is that the technology that much ruby code is working with is changing really really fast. Debian, god bless it, is not going to be a viable ruby deploy environment unless it can learn to accommodate that reality better.

    It is entirely normal for me to need different versions of a gem installed at any given time. Debian should not be in the business of deciding which one I should be using.

  3. I have been following your weblogs and individuals of other experts. Even now seeing which I’m not employing dark hat tacticts my site isn’t ranking. Could you inform me if I have repetitive pages on a different site would that harm me? I use calendars and descriptions of over 140 tunes indicates and reproduce which on one of my other domains. Coulkd that hurt my page ranking?

  4. Learned about it site from my friend. He pointed me right here and informed me I’d find which I necessity. He was correct! I got all the questions I had, answered. Didn’t also consider long to find it. Adore the fact that you forced it so simple for individuals enjoy me. More power

Comments are closed.