Ruby 1.9 isn't intended to production. It's a transitional release that aims to stabilize the code base to 2.0 release.<br><br>Probably it can't be on debian stable version!<br><br><br>Regards,<br>Luiz Vitor.<br>
<br><div class="gmail_quote">On Tue, Feb 3, 2009 at 12:24 PM, Lucas Nussbaum <span dir="ltr"><<a href="mailto:lucas@lucas-nussbaum.net">lucas@lucas-nussbaum.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
[ M-F-T set to debian-ruby@ ]<br>
<br>
Hi,<br>
<br>
We (Ruby interpreter maintainers) would like to hear the opinion of<br>
other people interested in Ruby on our proposed plans for Ruby in<br>
squeeze.<br>
<br>
After discussion will have happened on debian-ruby@, we will also ask<br>
the release team.<br>
<br>
Current status<br>
==============<br>
In lenny, we will ship two versions of the Ruby interpreter:<br>
<br>
Ruby 1.8 (the "stable" version) (package: ruby1.8 1.8.7.72-3)<br>
<br>
Ruby 1.9.0 (the "new stable" version) (package: ruby1.9 1.9.0.2-8)<br>
<br>
Both ruby1.8 and ruby1.9 source packages build several binary packages:<br>
- ruby1.n (with n=8,9) (arch: any, contains the interpreter binary<br>
and other things, very small)<br>
- libruby1.n (arch: any, contains /usr/lib/libruby1.n.so.1.n and<br>
most of the stdlib)<br>
- ruby1.n-dev (arch: any, provides headers, etc)<br>
- irb1.n, ri1.n, rdoc1.n (arch: all, provide developement tools)<br>
- some shared libs, such as libdbm-ruby1.n, libgdbm-ruby1.n,<br>
libopenssl-ruby1.n, etc. (arch: any, split out libruby1.n to<br>
remove some dependencies)<br>
<br>
Packages currently depend either on ruby1.n or libruby1.n when they<br>
need ruby 1.n.<br>
<br>
Ruby 1.8 plans<br>
==============<br>
It is not clear yet whether we will ship a ruby1.8 version in squeeze.<br>
It will depend on how fast Ruby 1.9 is adopted. It is highly<br>
possible that we decide to remove Ruby 1.8 from squeeze quite late in the<br>
release process, to avoid supporting it in a stable release.<br>
<br>
In all cases, we don't plan to change the way ruby 1.8 is packaged.<br>
<br>
Ruby 1.9 plans<br>
==============<br>
Ruby 1.9 is a different story. Upstream decided to version the API,<br>
and add a third digit to the library search path:<br>
/usr/lib/ruby/1.9.1 instead of /usr/lib/ruby/1.9<br>
Because of this, migrating from 1.9.0 (in lenny) to 1.9.1 (will be<br>
released upstream soon) won't be simple.<br>
<br>
We have two solutions:<br>
(A) allow for several ruby 1.9.{x,y} versions to be in the archive and<br>
installed at the same time, and do not support upgrades between them.<br>
(B) allow only one ruby1.9.{x,y} version to be in a given suite,<br>
provide upgrades between 1.9.{x,y}, and do mass-transitions of all<br>
ruby libs when a new 1.9.z is released. (ruby would have to migrate<br>
together with all its reverse-deps)<br>
<br>
We would prefer to do (B) since API changes are likely to be minor,<br>
and new 1.9.z releases are likely not to be too frequent (upstream<br>
said ~ once a year ; next is due Dec 09 or Jan 10).<br>
<br>
Proposed solution:<br>
<br>
1) drop the libruby1.9 package. Replace it with libruby1.9.1.<br>
ruby1.9 stays, but depends on libruby1.9.1. Here, "1.9.1" indicates<br>
the Ruby API version (or soname), not the version of Ruby. If Ruby<br>
1.9.2 stays API-compatible with 1.9.1, this will not be changed<br>
(according to the upstream developers).<br>
<br>
2) packages using ruby have to depend on libruby1.9.1. If they also<br>
require the interpreter, they need to also depend on libruby1.9.1,<br>
to indicate that they depend on this specific version of the API.<br>
Depending on ruby1.9 without depending on libruby1.9.1 is an RC bug.<br>
<br>
3) ask library maintainers to install to<br>
/usr/lib/ruby/vendor_ruby/1.9.1/ instead of /usr/lib/ruby/1.9.1/,<br>
to get out of the mix between standard libs and third-party libs.<br>
<br>
Migration plans:<br>
================<br>
1.9.0->1.9.1 migration:<br>
all packages have to be updated to depend on ruby1.9 and libruby1.9.1,<br>
and install their files in /usr/lib/ruby/vendor_ruby/1.9.1/<br>
<br>
1.9.1->1.9.2 migration, and later:<br>
all packages need to be updated to depend on ruby1.9 and libruby1.9.2,<br>
and install their files in /usr/lib/ruby/vendor_ruby/1.9.2/<br>
<br>
Open Questions:<br>
===============<br>
1) Should we allow for several ruby1.9.n versions in the same suite<br>
at a given time?<br>
<br>
2) Library packages naming: change from libxxx-ruby1.9 to something<br>
else? (would be nice to use that opportunity)<br>
ruby-xxx? (simpler)<br>
ruby1.9-xxx? stay with libxxx-ruby1.9?<br>
libxxx-ruby1.9.1 or ruby1.9.1-xxx? (required if we want to support<br>
several versions at the same time in the archive)<br>
<br>
<br>
So, comments? :-)<br>
--<br>
| Lucas Nussbaum<br>
| <a href="mailto:lucas@lucas-nussbaum.net">lucas@lucas-nussbaum.net</a> <a href="http://www.lucas-nussbaum.net/" target="_blank">http://www.lucas-nussbaum.net/</a> |<br>
| jabber: <a href="mailto:lucas@nussbaum.fr">lucas@nussbaum.fr</a> GPG: 1024D/023B3F4F |<br>
<font color="#888888"><br>
<br>
--<br>
To UNSUBSCRIBE, email to <a href="mailto:debian-ruby-REQUEST@lists.debian.org">debian-ruby-REQUEST@lists.debian.org</a><br>
with a subject of "unsubscribe". Trouble? Contact <a href="mailto:listmaster@lists.debian.org">listmaster@lists.debian.org</a><br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Regards, <br><br>Luiz Vitor Martinez Cardoso<br>cel.: (11) 8187-8662 <br>blog: <a href="http://rubz.org">rubz.org</a> <br>engineer student at <a href="http://maua.br">maua.br</a><br>
<br>"Posso nunca chegar a ser o melhor engenheiro do mundo, mas tenha certeza de que eu vou lutar com todas as minhas forças para ser o melhor engenheiro que eu puder ser"<br>