[DRE-maint] Ruby plans for squeeze

[Paul van Tilburg]

Hello all,

First of all I want to say that Lucas and I decided that Ruby 1.9.1 can
be uploaded independently from what we are currently doing/talking about. 
However, we should not bother fixing all the libs until we have clearly
decided on a policy.

Still, if you want to try out stuff, upload to experimental ONLY!
Thanks. :)

On Tue, Feb 03, 2009 at 03:24:42PM +0100, Lucas Nussbaum wrote:
> We (Ruby interpreter maintainers) would like to hear the opinion of
> other people interested in Ruby on our proposed plans for Ruby in
> squeeze.
> 
> 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.

Agreed.  We'll see about that when we get there.
I know of quite a few libs that are not Ruby 1.9-ready. 

> 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.

For me, the -ruby1.9 stuff was just experimental anyway, given
that 1.9.1 is the first stable 1.9-series release.
I expect we can work this out with dummy packages.

> 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.

This is going to be a pain and a lot of work.

> (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).

Agreed.  I also agree with what Adeodato said about this and have
nothing to add at the moment. 
It is obvious we need to examine the different cases and document what
needs to be done to get the current packages in Debian right and also
how new packages need to be set up.

> 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,

This should be: [...] need also depend on ruby1.9.

>    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.

Good idea.  Someone mentioned the /usr/share <> /usr/lib split up.
I am not entirely this cannot be done by the Debian Ruby interpreter
team and needs to be done upstream.  Can we not patch the default
$LOAD_PATH?  Please correct me if I am wrong.

> 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/

Either this or we use this symlink farm mentioned in previous mails.
It might be a good idea to look at Python here.  Maybe someone that
knows how this policy is actually implemented for the Python can
shed a light on this?  Duck? :)

Lucas asked me how to actually handle all this. Do we use the big-bang
approach and get all our libs that are available just for Ruby 1.8
to also provide a -ruby1.9.1 package and see what happens, or...
do we do this incrementally and check every lib thoroughly against
each version and then flag it (and how?)?

I'd say we go for the big bang approach, however... I think we need
some kind of a testing framework.  Something that after building a
package tries to run examples coming with the libraries in some clean
environment against the interpreter versions it is supposed to support. 
I do this manually in a non-clean environment now, but I sometimes
forget it and it's a lot of work.

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

Adeodato said the following:
> [...] That decision should depend, solely, on the answer to this
> question:  is there going to be software that says, "I work with Ruby
> 1.9.1, and won't release a version that is compatible with 1.9.2 in at
> least six more months"?  If the answer is "no" (and I hope that will
> be the case), then it really does not make sense to keep more than one
> 1.9.x release around (particularly since, at least for some time,
> 1.8.x will be around already).

I think however, the answer is "yes".  First of all... we have a lot of
libraries that have dead upstream.  Secondly, the weirdest upstream
things seem to happen in the Ruby community.

> 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?

This looks nice, but it will involve a wide upgrade path.  It depends on
the momentum we have within the group of Ruby libraries maintainers (I
don't mean the team, I mean everyone).   Do we think we have that?
I don't mind the current Perl naming scheme, but also the Python naming
scheme is nice because it matches more the things upstream uses.

Finally, lets not forget jruby.  We can see this as another interpreter
version instantiation.  So, don't we also need to have libjruby1.1 and
such things?

Paul

-- 
PhD Student @ Eindhoven                     | email: paulvt at debian.org
University of Technology, The Netherlands   | JID: paul at luon.net
>>> Using the Power of Debian GNU/Linux <<< | GnuPG key ID: 0x50064181