Differences between revisions 8 and 9
Revision 8 as of 2010-09-18 08:49:16
Size: 4256
Comment:
Revision 9 as of 2010-09-18 08:50:36
Size: 4394
Comment:
Deletions are marked like this. Additions are marked like this.
Line 43: Line 43:
=== Use the alternatives system ===
<<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>>
The alternatives system would allow to easily switch between Ruby 1.8 and Ruby 1.9.X (instead of the current "/usr/bin/ruby is a symlink to ruby1.8" approach). However, this requires rethinking how we package Ruby applications and libraries, to make sure that those that only work with one particular Ruby version will be correctly treated. We cannot just break them all.
Line 48: Line 44:
<<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>> <<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>>
Line 54: Line 50:
Many things need to be well thought, like how to handle dependencies. Which makes this task quite hard to approach.

=== Use the alternatives system ===
<<Icon(star_on.png)>><<Icon(star_on.png)>><<Icon(star_on.png)>>
The alternatives system would allow to easily switch between Ruby 1.8 and Ruby 1.9.X (instead of the current "/usr/bin/ruby is a symlink to ruby1.8" approach). However, this requires rethinking how we package Ruby applications and libraries, to make sure that those that only work with one particular Ruby version will be correctly treated. We cannot just break them all.

The Debian/Ruby Teams

The Debian/Ruby teams maintain the Ruby interpreters, libraries and applications. There are actually two different Ruby teams in Debian:

  • the pkg-ruby team maintains the interpreter
  • the pkg-ruby-extras team maintains libraries and applications

Most discussions happen on the http://lists.debian.org/debian-ruby/ debian-ruby@ mailing list. Discussions specific to pkg-ruby-extras also happen on the http://lists.alioth.debian.org/mailman/listinfo/pkg-ruby-extras-maintainers pkg-ruby-extras-maintainers@ list. You should be subscribed to both if you want to follow Ruby in Debian.

We also use IRC (#debian-ruby on irc.debian.org) quite a lot.

pkg-ruby

How you can help:

  • {*} Subscribe to the pkg-ruby packages (ruby1.8, ruby1.9.1, ruby-defaults) on the Packages Tracking System, and then contribute to the bug mail you get. (It is a good idea to also subscribe to bugmail from Ubuntu, see http://www.debian.org/doc/developers-reference/resources.html#pts-commands developers reference for details).

  • {*} Go through bugs, see if you can reproduce them and provide more information. Report them upstream when needed.

  • {*}{*} Checkout the SVN repository, see if you can provide a patch for some issues.

pkg-ruby-extras

How you can help:

  • {*} Subscribe to the lists, and start contributing to solving bugs.

  • {*} Use the Packages overview to go through all existing bugs, and see if you can help with solving some of them.

  • {*}{*} Checkout the SVN repository, and see if you can improve the existing packages. There are many things that can be improved!

Mid- and Long-term tasks

Move the pkg-ruby-extras website to the Debian wiki

{*} The pkg-ruby-extras website is difficult to maintain. It would be easier if everywhere was on the Debian wiki, either on this page or in sub-pages.

Backports

{*} Provide backports for the key Ruby packages (interpreter, rubygems) for both Debian and Ubuntu stable releases.

Revamp the libraries packaging helper

{*}{*}{*}{*} Our current approach is based on cdbs, and duplicates a lot of code between binary packages when we provide both 1.8 and 1.9.X packages. It would be much better if we only had one package when the library works with both. Also, we need somehow to work with rubygems (this is a bit too hard currently). The approach could be:

  • have a gem2tgz script that generates a clean tarball as a basis for packaging work.
  • have a dh-make-ruby script that converts the tarball into a Debian source package, using the gem metadata as a basis
  • have a dh_ruby helper that would handle installing with either a modified setup.rb or a modified extconf.rb, run tests, etc.

Many things need to be well thought, like how to handle dependencies. Which makes this task quite hard to approach.

Use the alternatives system

{*}{*}{*} The alternatives system would allow to easily switch between Ruby 1.8 and Ruby 1.9.X (instead of the current "/usr/bin/ruby is a symlink to ruby1.8" approach). However, this requires rethinking how we package Ruby applications and libraries, to make sure that those that only work with one particular Ruby version will be correctly treated. We cannot just break them all.