[DRE-maint] Ruby plans for squeeze

[Lucas Nussbaum]

[ M-F-T set to debian-ruby@ ]

Hi,

We (Ruby interpreter maintainers) would like to hear the opinion of
other people interested in Ruby on our proposed plans for Ruby in
squeeze.

After discussion will have happened on debian-ruby@, we will also ask
the release team.

Current status
==============
In lenny, we will ship two versions of the Ruby interpreter:

Ruby 1.8 (the "stable" version) (package: ruby1.8 1.8.7.72-3)

Ruby 1.9.0 (the "new stable" version) (package: ruby1.9 1.9.0.2-8)

Both ruby1.8 and ruby1.9 source packages build several binary packages:
- ruby1.n (with n=8,9) (arch: any, contains the interpreter binary
  and other things, very small)
- libruby1.n (arch: any, contains /usr/lib/libruby1.n.so.1.n and
  most of the stdlib)
- ruby1.n-dev (arch: any, provides headers, etc)
- irb1.n, ri1.n, rdoc1.n (arch: all, provide developement tools)
- some shared libs, such as libdbm-ruby1.n, libgdbm-ruby1.n,
  libopenssl-ruby1.n, etc. (arch: any, split out libruby1.n to
  remove some dependencies)

Packages currently depend either on ruby1.n or libruby1.n when they
need ruby 1.n.

Ruby 1.8 plans
==============
It is not clear yet whether we will ship a ruby1.8 version in squeeze.
It will depend on how fast Ruby 1.9 is adopted. It is highly
possible that we decide to remove Ruby 1.8 from squeeze quite late in the
release process, to avoid supporting it in a stable release.

In all cases, we don't plan to change the way ruby 1.8 is packaged.

Ruby 1.9 plans
==============
Ruby 1.9 is a different story. Upstream decided to version the API,
and add a third digit to the library search path:
/usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9
Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be
released upstream soon) won't be simple.

We have two solutions:
(A) allow for several ruby 1.9.{x,y} versions to be in the archive and
installed at the same time, and do not support upgrades between them.
(B) allow only one ruby1.9.{x,y} version to be in a given suite,
provide upgrades between 1.9.{x,y}, and do mass-transitions of all
ruby libs when a new 1.9.z is released. (ruby would have to migrate
together with all its reverse-deps)

We would prefer to do (B) since API changes are likely to be minor,
and new 1.9.z releases are likely not to be too frequent (upstream
said ~ once a year ; next is due Dec 09 or Jan 10).

Proposed solution:

1) drop the libruby1.9 package. Replace it with libruby1.9.1.
   ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates
   the Ruby API version (or soname), not the version of Ruby. If Ruby
   1.9.2 stays API-compatible with 1.9.1, this will not be changed
   (according to the upstream developers).

2) packages using ruby have to depend on libruby1.9.1. If they also
   require the interpreter, they need to also depend on libruby1.9.1,
   to indicate that they depend on this specific version of the API.
   Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.

3) ask library maintainers to install to
   /usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,
   to get out of the mix between standard libs and third-party libs.

Migration plans:
================
1.9.0->1.9.1 migration:
all packages have to be updated to depend on ruby1.9 and libruby1.9.1,
and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/

1.9.1->1.9.2 migration, and later:
all packages need to be updated to depend on ruby1.9 and libruby1.9.2,
and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/

Open Questions:
===============
1) Should we allow for several ruby1.9.n versions in the same suite
at a given time?

2) Library packages naming: change from libxxx-ruby1.9 to something
else? (would be nice to use that opportunity)
ruby-xxx? (simpler)
ruby1.9-xxx? stay with libxxx-ruby1.9?
libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support
several versions at the same time in the archive)


So, comments? :-)
-- 
| Lucas Nussbaum
| lucas at lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr             GPG: 1024D/023B3F4F |