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.

System calls quizz

  1. What is special about the socket, connect, bind, accept, … system calls?
  2. How does the errno value get from the kernel to applications?
  3. Some system calls return a number of times different of 1 in some cases. Which ones? (Put differently: enter a syscall once, exit more or less than once. Which ones can do that?)

(Thanks MG!)

RVM: seriously?

There’s some hype in the Ruby community about RVM (Ruby Version Manager). It’s a tool that allows to switch between Ruby versions on the same system (much like what the alternatives system provides for Java on Debian, except that RVM does it either system-wide or per-user).

However, when you look at it, RVM looks quite scary.

The recommended installation instruction is:
bash < <( curl ).
That script doesn’t use set -e, and actually does a git clone behind the scenes. Without first checking that git is installed. But if you don’t have git installed, it’s not a problem: there’s another script later on the page that downloads and compiles it for you.

After installing RVM itself, you need to install rubies (different ruby implementations). Use rvm install ree,1.9.2-head,jruby. That will automatically download and build the various versions in your homedir. It’s interesting to note the the compilation messages were probably too scary, and are not displayed.

But how does it handle the switch between different versions ? First, you need to add some magic to your .bashrc:
[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"
or, for a system-wide install of rvm:
[[ -s "/usr/local/rvm/scripts/rvm" ]] && . "/usr/local/rvm/scripts/rvm"
And then, you can select your ruby implementation using rvm --default 1.9.2, for example. That works by redefining $PATH:
# echo $PATH

Of course, that’s quite fragile: if you are in one of the cases where bash doesn’t read .bashrc, or if you happen to be using dash, you lose.

Looking at the code of RVM itself, it is also very fragile: it’s pure bash, without any error handling. During my test (in a chroot), I often got error messages about missing commands that were apparently ignored. The installer insists on using colors, and spews lots of error messages if executed without a controlling tty. There are also some interesting code snippets like perl -e 'sleep 0.5'.

So, where do we go from here? Well, obviously, with my Debian hat, I’m not going to advocate a solution that makes everything possible to avoid the distribution’s packaging system, and I don’t see RVM being packaged in Debian anytime soon.
In Debian, we already provide co-installability of Ruby 1.8 and 1.9.2, and users are free to choose which one to use on a per-script basis, by running them with version-suffixed ruby executables. The ‘ruby’ executable itself still points to 1.8, as it’s clearly too early to make 1.9.2 the default. Many Ruby libraries are provided for both 1.8 and 1.9.2, and we plan to discuss changes in the packaging system to be able to make it easier to provide packages for both versions. There’s also recent work on packaging JRuby, but it’s quite hard as it requires removing all the non-free or undistributable parts, and packaging them separately.

Ubuntu bugs with patches on the PTS and the QA Packages Overview

Like the Debian BTS, Launchpad is full of open bugs with patches[1]. They have an ongoing effort called Operation Cleansweep whose goal is to get the number of bugs with patches to zero, by reviewing patches and forwarding them upstream or to Debian.

Since it really makes sense to expose bugs with patches to the Debian maintainers, I’ve modified the Ubuntu box on the Packages Tracking System and the Ubuntu column on the QA Packages Overview (hidden by default for now) to include that information. You can see the result on the dpkg PTS page and the debian-pkg@ packages overview page.

Many thanks to Brian Murray for making this possible on the Launchpad side.

[1] Debian has 55115 open bugs affecting unstable, of which 4011 have a patch. Ubuntu has 76916 open bugs, of which 2207 have a patch. [Insert here disclaimer that this is not at all a judgement of value on the abilities of any distribution at triaging bugs, or at generating patches]
Relevant UDD queries:

select count(*) from bugs
where affects_unstable and status = 'pending'
and id in (select id from bugs_tags where tag ='patch');

select count(*) from bugs
where affects_unstable and status = 'pending';

select count(distinct bugs.bug)
from ubuntu_bugs_tasks tasks,ubuntu_bugs bugs
where tasks.bug = bugs.bug
and distro in ('', 'Ubuntu')
and status not in ('Invalid', 'Fix Released', 'Won''t Fix')
and bugs.patches is true;

select count(distinct bugs.bug)
from ubuntu_bugs_tasks tasks,ubuntu_bugs bugs
where tasks.bug = bugs.bug
and distro in ('', 'Ubuntu')
and status not in ('Invalid', 'Fix Released', 'Won''t Fix');

Debcamp+Debconf again! (update)

As I did since 2007, I will be attending Debconf again this year. I have been quite busy recently, and am lagging behind in some of my Debian work, so I plan to use Debconf to get stuff done, not just socialize and attend talks.

Here is my TODO list, basically by order of “willingness to do the work”. It’s probably too much for 9 days, so don’t hesitate to talk to me if you want to help with some items.

  • Switch the ruby1.9.1 package to a prerelease of Ruby 1.9.2. That package providing the development branch of the interpreter. That will be done while keeping the existing package name, as Ruby 1.9.1 and 1.9.2 are (supposed to be) compatible. It might be a bit confusing for users to have a ruby1.9.1 package that installs Ruby 1.9.2, but then we can just blame the upstream developers for using the same numbering space for “ruby compatibility level” and “ruby version”. Bonus: will fix 2 FTBFS on {kfreebsd-,}i386. ruby1.9.1 1.9.2~svn28788-1 uploaded, but it really means “ok, enough, let’s upload and see what happens”. There are some open issues on FreeBSD, and some patches that still require porting to that version.
  • Update the ruby1.8 package. There’s a few patches pending (including the “ruby is slow because of pthread” one). ruby1.8 uploaded, sync to Ubuntu requested.
  • Run an archive-wide test using instest again. instest is a piuparts re-implementation that is targetted at making it easy to file bugs about installation and removal failures. It’s nothing big, really, but already allowed to file 78 RC bugs a few months ago. Done, and call for help posted. Which raises another TODO item:
    • Process instest failures if nobody wants to help … Well, done partially. The number of issues found justifies that those tests are useful, so I’m a bit annoyed that nobody volunteered to help.
  • Run an archive rebuild. I did one last week-end mainly to provide food for RCBC, but there are some failures that haven’t been filed because they required more investigation. I also need to check back with various people about some custom rebuilds (newer GCC, etc). And I’ll probably also do a rebuild of Ubuntu maverick.Rebuild done, about 70 new RC bugs filed, and some cleanup done on old unreproducible bugs. Also did a rebuild with an updated hardening-wrapper for Raphael Geissert, and a rebuild of Ubuntu maverick on i386 and amd64 (results posted on ubuntu-devel@).
  • Do a ddpo-by-mail run. Last one was a longgg time ago. I have a few open requests about ddpo-by-mail that I’d like to address before spamming people again (for example, it shouldn’t report about merged bugs).Done, ~1300 emails sent.
  • Ultimate Debian Database work: merge the upload-history importer into UDD itself to drop the dependency on a script on merkel. Also address #540132 (strange info in the upload-history table). Make sure the changes to carnivore about DMs are compatible with the carnivore importer. All done!
  • Investigate how we could improve Ruby packaging with something like ruby-support. One of the requirements is to provide an easier way to support several Ruby versions.
  • Do some work on feed2imap. It got a few valid feature requests recently that I’d like to address in a 1.1 release.
  • Debian/Ubuntu work: add info about bugs with patches to the PTS now that this info is available in UDD thanks to Brian Murray’s work on the Launchpad side, and other pending work items from the Debian/Ubuntu BOF at UDS
  • Work on Bapase and the handling of poorly maintained and low-quality packages, resurrecting an old thread on debian-qa@
  • Do some packaging work: systemtap 1.3, tcsh, websec (long overdue!), and the usual pkg-ruby-extras shores. I also would like to take a look at the atlas FTBFS as I’m affected through hpcc.
  • Update developers-reference. I’m totally in lazy mode about that since the maintenance was transferred to debian-policy@, but I will try to address bugs with valid patches.

#debian-ubuntu on OFTC

If you are a Debian developer and need realtime interaction with an Ubuntu developer about the state of your packages in Ubuntu (or vice-versa), #debian-ubuntu on might be useful. I had forgotten about that channel, but it resurfaced during the discussions about improving communication between both projects.

EtherPad: web-based collaborative editor

I recently (during a UDS lightning talk) discovered EtherPad. It’s a collaborative editor (like gobby), but uses a browser instead of a standalone application. It’s free software (Google open sourced it after buying the company that was developing it), and there’s a free online instance at Setting up a new pad is as simple as going to and clicking Create Pad. It’s written in Java, and not packaged in Debian (yet).

XMPP Video calls with Nokia N900

So, this morning, I did my first video call over XMPP between two N900.

However, so far, I failed to do an XMPP video call from an N900 to something else. When I try to call pidgin on my laptop, pidgin simply crashes, but of course that’s not a serious bug if people can DOS your pidgin instance since, according to the Debian bug:

Assuming your XMPP settings require that users must authenticate with you before being able to send you messages, only your authenticated users would be able to freeze your client, assuming they knew you were actually affected by this bug.

The upstream pidgin bug hasn’t seen a lot of activity lately. :-(