Re: Ruby 1.9.1 package release plan
On 21/07/09 at 10:39 +0900, akira yamada wrote:
> Hi,
>
> I and Daigo-san had a meeting with some Japanese Debian users at 2009-07-05.
> We discussed about new Ruby policy and other ruby1.9 issues on Debian.
> (We plans to translate the summary of the meeting to English in near future.)
>
> We (the attenders of the meeting) think that
> we should discuss new policy plan (and ruby-support issue)
> separately from "new ruby1.9 package into sid".
> Many people on sid are waiting for ruby1.9_1.9.1.x :-)
> And new useful support system can come later.
>
> So maintainers have plans about "ruby1.9 into sid".
>
>
> [1] ruby1.9.1 package provides Ruby 1.9.1
>
> This is Lucas's plan.
>
> Here "1.9.1" denotes "ruby compatibility level".
> It appears in $LOAD_PATH such as /usr/lib/ruby/<1.9.1>.
>
> "Ruby 1.9.2" will have the same compatibility level of "Ruby 1.9.1".
> "Ruby 1.9.2" is compatible with Ruby "1.9.1".
> And $LOAD_PATH of "Ruby 1.9.2" is /usr/lib/ruby/1.9.1.
>
> So we will release Ruby 1.9.2 package as "ruby1.9.1".
> Lucas, is it O.K.?
No, we could release Ruby 1.9.2 as ruby1.9.2 and have it provide
ruby1.9.1 if it is compatible.
> [2] upgrade ruby1.9_1.9.0.2 to ruby1.9_1.9.1.243
>
> This is by Daigos-san and me.
>
> The upstream authors said
> "please use Ruby 1.9.1 and do not use Ruby 1.9.0".
> I agree that.
>
> On Debian, we want to provide new Ruby 1.9.1 asap.
> And we don't want to introduce new complexity.
>
>
> [Pros/Cons]
>
> [1]
> - o - we can co-install Ruby 1.9.0 and Ruby 1.9.1 for transition.
> - x - ruby1.9.1 package and /usr/bin/ruby1.9.1 is bit complex. (Ruby 1.9.0 will remove for squeeze.)
> - x - new package may take time to install to sid.
What do you mean with "new package may take time to install to sid"?
> [2]
> - o - no new package isn't take time.
> - x - introduces RC-bug to existent packages (lib*-ruby1.9)
What do you mean with "no new package isn't take time."?
With your plan ([2]), the new ruby1.9 package (using ruby 1.9.1) would
break all the existing libs named *-ruby1.9. Those libs would have to be
transitionned so that files are installed elsewhere (moving files from
/usr/lib/ruby/1.9.0 to /usr/lib/ruby/1.9.1). Transitionning all those
libraries, and doing it again for ruby1.9.2 or 1.9.3 (when the API
changes) is going to be extremely painful. With the current amount of
manpower, it will probably take a few months before ruby libs are no longer
broken in unstable.
With my plan ([1]) (ruby1.9.1 package providing /usr/lib/ruby1.9.1,
co-installable with ruby1.9(.0)), we can:
1) provide ruby 1.9.1 to users who want to use it now (using gems and
such)
2) avoid transitionning libs now, and wait until ruby-support is ready
(which will make future migrations easier)
Sure, typing ruby1.9.1 is harder than typing ruby for the user. We could
use alternatives so that the user can select the version of ruby he
wants, but then we would have to fix all the ruby applications that use
/usr/bin/ruby first (so that they hardcode the version of ruby they want
to work with).
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: