Ruby 1.9.1 package release plan

[akira yamada]

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


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

[2]
 - o - no new package isn't take time.
 - x - introduces RC-bug to existent packages (lib*-ruby1.9)


[Comments?]

Which do you like [1] or [2]?  Or the another plan?

Thank you.


[In Japanese]

ご存知の方もいらっしゃるかもしれませんが
Debian Ruby 1.9会議というのを2009-07-05に開催しました。
daigoさんと私の他に8人のDebianユーザやDebian開発者が集まりました。
主な目的はDebianにおける新しいRubyポリシーの議論を日本語で行うことでしたが
それ以外にもDebianにおけるRuby 1.9およびRubyに関する広い話題について議論しました。

現在、というには少し時間がかかってしまっていますが議論のサマリーを作成しているところです。
できるだけ早くに公開するつもりです(英語にしてdebian-ruby@.orgに流すつもりです)

その議論での合意の一つとして
できるだけ早くRuby 1.9環境をDebian/sidに確立しようというのがあります。
現在、Ruby 1.9.0.2という、今となっては推奨されないバージョンの
Ruby 1.9がsidにはあります。これはRubyユーザにとっても
Ruby開発者にとっても好ましい状態ではありません。
明確に「Ruby 1.9.1を使ってほしい」と言われているのが今の状況です。

そのため「新ポリシー案」のこととは独立に
ruby1.9パッケージを更新しようとLucasさんに持ちかけたわけですが
パッケージ名について異論が出てしまいました。

Lucasnさん案:

 - ruby1.9.1という名前にする(インタプリタは/usr/bin/ruby1.9.1)
 - なぜならruby1.9と同時にインストールできるから(既存パッケージに影響を与えない)

daigoさんと私の案:

 - ruby1.9をそのまま更新する
 - 早くsidにinstallされる
 - 複雑さをまねかない

互いに利点・欠点が裏返しの関係になっているといえると思います。
Lucasさん案では以下に述べるように物事が複雑になります。
私たちの案では既存パッケージ(lib*-ruby1.9)がRCバグ持ちになってしいます。

複雑さというのは、パッケージ数が増えるというのが第一ですが
もうひとつ互換性レベルへの配慮という問題があります。
「ruby1.9.1」という名前にした場合、個人的には
「1.9.1」の部分がRuby 1.9における互換性レベルを示すべきだと考えています。
(これはLucasさん案では明示されていない点で、私が考えたことです。)
互換性レベルというのはRuby 1.9.1以降で導入されたもので
RubyスクリプトやRubyバイナリの互換性へ表します。
(Rubyには、Ruby本体、soname、互換性レベルの三つのバージョンがあります。)
パッケージ運用の点から、もしも「ruby1.9.1」のような名命規則とするなら
「1.9.1」の部分は互換性レベルに従うべきだと考えます。

なお、RCバグ持ちになること自体についてですが
squeezeまでにRuby 1.9.0は削除されるべきですから
必要なRCバグだと個人的には考えています。

このメールの前半では、私のへた英語を書いてしまっているように
この問題については英語での議論が必要とされています。
もしコメントがありましたらdebian-ruby@.orgに投げていただけるとありがたいです。
(英語でおぎなってもらえるとうれしい…… ^_^;)

よろしくお願いします。

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

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@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[akira yamada]

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

But squeez can include only one Ruby 1.9.x package.
Or we shoud have some ruby1.9.x packages on squeeze?

> Sure, typing ruby1.9.1 is harder than typing ruby for the user. We could

I think that complexty is a problem...

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

I don't like alternatives for that usage.
Users assume all alternatives works fine with all other programs.
(ruby1.9(.0) foo.rb, ruby1.9(.1) foo.rb and ruby1.9(.2) works as the same.)

We should have standard "ruby" for users and packages.
I think that "/usr/bin/ruby" should be provided by a package
such as ruby-default.

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Yasuhiro Araki-2]

lucas,

On Tue, Jul 21, 2009 at 5:16 PM, Lucas Nussbaum<lucas@...> wrote:

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

Sure. Yes we can!  However, I agree to [2] upgrade ruby1.9_1.9.0.2 to
ruby1.9_1.9.1.243.

Because it reduce our maintenance resource.
Ruby1.9.1 upstream team will stop support by after a half year of
ruby.1.9.2 release.
And they promise to provide ruby1.9.2 as ruby1.9.1 successor (binary
compatible).

If we select [1], we should support ruby1.9.1.deb after vanished by upstream.
Actually, supporting ruby1.9.1 means supporting ruby1.9.2.

>> [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. However, I believe "sid" user can hold his system to avoid
destructive ruby1.9.deb environment change.

> 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@...   http://www.lucas-nussbaum.net/ |
> | jabber: lucas@...             GPG: 1024D/023B3F4F |
>
>
> --
> To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
> with a subject of "unsubscribe". Trouble? Contact listmaster@...
>
>

--
ARAKI Yasuhiro


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 21/07/09 at 18:20 +0900, Yasuhiro Araki wrote:

> Sure. Yes we can!  However, I agree to [2] upgrade ruby1.9_1.9.0.2 to
> ruby1.9_1.9.1.243.
>
> Because it reduce our maintenance resource.
> Ruby1.9.1 upstream team will stop support by after a half year of
> ruby.1.9.2 release.
> And they promise to provide ruby1.9.2 as ruby1.9.1 successor (binary
> compatible).
>
> If we select [1], we should support ruby1.9.1.deb after vanished by upstream.
> Actually, supporting ruby1.9.1 means supporting ruby1.9.2.

The fact that ruby1.9.0's support will end sooner (or ruby1.9.1's
support) is a bit pointless: we will have to support it during squeeze's
lifetime anyway. Also, having two (or more) versions at one point in
unstable doesn't mean that we will release squeeze with more than one
version.

Doing what you suggests reduces the maintainance of the ruby1.9 package,
but increases the one of the 200+ ruby libraries packaged in Debian.

> > 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. However, I believe "sid" user can hold his system to avoid
> destructive ruby1.9.deb environment change.

But then, users won't get 1.9.1 and will have to stay with 1.9.0 until
all the libs they use have transitionned.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 21/07/09 at 17:54 +0900, akira yamada wrote:

> > 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.
>
> But squeez can include only one Ruby 1.9.x package.
> Or we shoud have some ruby1.9.x packages on squeeze?

I agree that squeeze should only have one ruby 1.9.x package.

> > Sure, typing ruby1.9.1 is harder than typing ruby for the user. We could
>
> I think that complexty is a problem...

We are discussing typing "ruby1.9 foo.rb" instead of "ruby1.9.1 foo.rb".
That's only two bytes!

> > 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).
>
> I don't like alternatives for that usage.
> Users assume all alternatives works fine with all other programs.
> (ruby1.9(.0) foo.rb, ruby1.9(.1) foo.rb and ruby1.9(.2) works as the same.)
>
> We should have standard "ruby" for users and packages.
> I think that "/usr/bin/ruby" should be provided by a package
> such as ruby-default.

Having packages use /usr/bin/ruby is a problem when we want to switch
from ruby1.8 to ruby1.9 for /usr/bin/ruby. We should check that every
package using /usr/bin/ruby works with ruby1.9 first.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Daigo Moriwaki]

Hello,

A couple of comments.

akira yamada wrote:
> 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.)

The purpose of the meeting was that we had a chance to hear about possible
complaints and good ideas that users might have, of course not to ask for a
super visor of the package management.


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

This proposal is a tentative and one-shot approach just for Ruby 1.9.1, not for
Ruby 1.9.z all the way long in the future. We can and should continuously
discuss and develop the new Debian Ruby policy and tools such as ruby-support.
It will take time for them to be matured. Fortunately, the coming Ruby 1.9.2
will install into /usr/lib/ruby/1.9.1. Ruby 1.9.3 may or may not be compatible
with 1.9.1. We will have to be prepared by the Ruby 1.9.3 release.


Regards,
Daigo

--
Daigo Moriwaki
beatles at sgtpepper dot net


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[akira yamada]

>>> Sure, typing ruby1.9.1 is harder than typing ruby for the user. We could
>> I think that complexty is a problem...
> We are discussing typing "ruby1.9 foo.rb" instead of "ruby1.9.1 foo.rb".
> That's only two bytes!

Many ruby1.9.x packages in Debian is the problem, I think.

You said "users won't get 1.9.1 and will have to stay with 1.9.0 until
all the libs they use have transitionned".

But Users only wait (some) packages used by themself.
And they can submit a bug to push transitions.
(Or they can make a patch!)

If we provide ruby1.9.x packages for Debian/sid users,
they may miss new version of Ruby 1.9 in Debian.
They may stay in Ruby 1.9.0 even if they don't intend.

Note:

 * http://www.ruby-lang.org/en/news/2007/12/25/ruby-1-9-0-released/
   "Matz announced the release of Ruby 1.9.0, a development release"

 * http://www.ruby-lang.org/en/news/2009/01/30/ruby-1-9-1-released/
   "Ruby 1.9.1 is released. This is the first stable release of the Ruby 1.9 series."

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[akira yamada]

>>> 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).
>> I don't like alternatives for that usage.
>> Users assume all alternatives works fine with all other programs.
>> (ruby1.9(.0) foo.rb, ruby1.9(.1) foo.rb and ruby1.9(.2) works as the same.)
>>
>> We should have standard "ruby" for users and packages.
>> I think that "/usr/bin/ruby" should be provided by a package
>> such as ruby-default.
>
> Having packages use /usr/bin/ruby is a problem when we want to switch
> from ruby1.8 to ruby1.9 for /usr/bin/ruby. We should check that every
> package using /usr/bin/ruby works with ruby1.9 first.

I agree.

But I intended to say that
alternatives is not fit for that usage.

If we proved ruby1.9.x packages and
we use alternatives for all ruby1.9.x,
we should check many packages.

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 22/07/09 at 08:24 +0900, akira yamada / ?????? wrote:

> >>> 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).
> >> I don't like alternatives for that usage.
> >> Users assume all alternatives works fine with all other programs.
> >> (ruby1.9(.0) foo.rb, ruby1.9(.1) foo.rb and ruby1.9(.2) works as the same.)
> >>
> >> We should have standard "ruby" for users and packages.
> >> I think that "/usr/bin/ruby" should be provided by a package
> >> such as ruby-default.
> >
> > Having packages use /usr/bin/ruby is a problem when we want to switch
> > from ruby1.8 to ruby1.9 for /usr/bin/ruby. We should check that every
> > package using /usr/bin/ruby works with ruby1.9 first.
>
> I agree.
>
> But I intended to say that
> alternatives is not fit for that usage.
>
> If we proved ruby1.9.x packages and
> we use alternatives for all ruby1.9.x,
> we should check many packages.

That could be a useful goal for squeeze.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[akira yamada]

>> But I intended to say that
>> alternatives is not fit for that usage.
>>
>> If we proved ruby1.9.x packages and
>> we use alternatives for all ruby1.9.x,
>> we should check many packages.
>
> That could be a useful goal for squeeze.

squeeze includes only one Ruby 1.9 package.
alternatives is not needed.

My opinion:
 * package name of Ruby 1.9.1 shoud be "ruby1.9"
   (many ruby1.9.x packages and many /usr/bin/ruby1.9.x
   introduce unnecessary complexty.)
 * we should not use alternatives for /usr/bin/ruby1.*
   (we should have "standard ruby" or "standard ruby1.9".)

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

Hi,

in order to help everybody have a global view of the issue, I've tried
to write a summary (see attachment).

Disclaimer: my opinion might bias it a bit.

Is there a way to insert HTML on wiki.debian.org? I would prefer
avoiding converting it to wiki syntax.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |

ruby 1.9.1 (and beyond) packaging

Solutions	Re-use the ruby1.9 source package	New ruby1.9.1 source package, co-installable with the ruby1.9(.0) packages
Source package name	ruby1.9	ruby1.9.1
Binary packages names	ruby1.9, libruby1.9, etc.	ruby1.9.1, libruby1.9.1, etc.
Interpreter executable	/usr/bin/ruby1.9	/usr/bin/ruby1.9.1
How will the user run scripts?	ruby1.9 foo.rb for 1.9.0 or 1.9.1, depending on the package installed	ruby1.9 foo.rb for 1.9.0, ruby 1.9.1 foo.rb for 1.9.1
Transition for users from 1.9.0 (current unstable version) to 1.9.1	1.9.1 will replace 1.9.0	1.9.1 can be co-installed with 1.9.0 (similar to kernel versions)
Third-party library transitions (packaged)	Installating the 1.9.1 version of ruby1.9 will break all the 1.9.0 library packages. They will have to be transitionned to install files in the right place (/usr/lib/ruby/1.9.1). Question: should we add a Breaks: field in the libruby1.9 package for 1.9.1?	Installing ruby1.9.1 won't break the 1.9.0 libraries, which will continue to work with Ruby 1.9.0. But libraries still have to be transitioned to 1.9.1.
Third-party library transitions (manually installed via setup.rb or extconf.rb)	Installating the 1.9.1 version of ruby1.9 will break all the manually installed 1.9.0 library packages (which were installed in 1.9.0 dirs). The user will have to re-install them.	The libraries will continue to be usable with ruby 1.9.0 (using ruby1.9 foo.rb). To use them with 1.9.1, the user will need to re-install them.
Third-party library transitions (installed using gems)	Same status as third-party libs installed manually, since gems are installed in /var/lib/gems/1.9.X/
What about ruby 1.9.2 ? Ruby 1.9.2 is supposed to be API/ABI compatible with ruby 1.9.1 (which means that its loadpath is supposed to stay the same)	The same ruby1.9 source package will be updated to 1.9.2	We can switch to a ruby1.9.2 source package (for consistency) which will Conflict, Replace, Provide the ruby1.9.1 package. Or we can re-use the ruby1.9.1 source package with 1.9.2 binary packages (since that's hidden for the user). Or we can re-use the 1.9.1 source package with 1.9.1-named but really 1.9.2 binary packages, just to avoid going through NEW.
What about ruby-support (automatic support of several ruby versions for pure-ruby libs)	ruby-support would still be useful. Once packages are transitioned to r-s, they will no longer require manual intervention to support new ruby versions	r-s will allow to automatically support all the installed ruby versions for pure-ruby libs
What about squeeze?	In squeeze, we will release Ruby 1.9.x (x likely to be 2). there will only be one ruby1.9 source package.	In squeeze, it would be much better to release only one ruby1.9.x package (likely ruby1.9.2). We will need to make sure that ruby1.9.1 and ruby1.9 can safely be removed (not too hard if many libs transition to ruby-support)
What about the "ruby" command?	This is an orthogonal issue, since the ruby command is provided by the ruby-defaults source package. At some point, we will decide to switch to ruby 1.9.x for the ruby command (currently ruby 1.8). Another option could be to use alternatives so that the user can decide (but no consensus on this ; the problem is that many applications use /usr/bin/ruby, and might break).
OK, how does our TODO list look like?	Upload ruby1.9 1.9.1.x to sid. File RC bugs on all packages providing 1.9.0 libs (~40 packages) Transition all those packages to 1.9.1 (through ruby-support, if it is ready, or manually)	Upload ruby1.9.1 1.9.1.x to sid. Alternatively: Wait until ruby-support is really ready, then transition pure-ruby packages to ruby-support (win: automatically support 1.9.0 and 1.9.1 Transition packages providing 1.9.0 libs to 1.9.1 (we could decide on a per-package basis, users will be able to install libs with gems anyway) Remove ruby1.9 source package (providing 1.9.0)
Major pros	Simpler for the ruby interpreter maintainers (only one 1.9 source package to maintain)	User can choose between 1.9.0 and 1.9.1 No breakage for the user (1.9.0 libs continue to work during the transition) Third-party libraries can wait until ruby-support is ready Less pressure on the library packagers: less urgency to transition libs
Major cons	Massive breakage of third-party libs Mass transition of third-party If done now, ruby-support is not ready => need to transition again for ruby-support	User will end-up with 1.9.0 and 1.9.1 both installed. Needs cleanup at some point (similar to kernel packages). Need to maintain two 1.9.x versions in testing/unstable for some time Need to go through NEW

[akira yamada]

Hi,

> Source package name
> ruby1.9.1

Why you switch source package name to "ruby1.9.1"?

> OK, how does our TODO list look like?
> * Transition packages providing 1.9.0 libs to 1.9.1

What do "transition packages" include in?

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 23/07/09 at 06:27 +0900, akira yamada / やまだあきら wrote:
> Hi,
>
> > Source package name
> > ruby1.9.1
>
> Why you switch source package name to "ruby1.9.1"?

because you need to change the source package name so that both sets of
packages will exist in unstable at the same time. If you re-use ruby1.9
with ruby1.9.1 binary package, the ruby1.9 will be removed.

> > OK, how does our TODO list look like?
> > * Transition packages providing 1.9.0 libs to 1.9.1
>
> What do "transition packages" include in?

Ooops, it's "transition" as a verb, not as a noun.
="We need to make a transition of all packages providing 1.9.0 to 1.9.1."
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[akira yamada]

>>> Source package name
>>> ruby1.9.1
>> Why you switch source package name to "ruby1.9.1"?
>
> because you need to change the source package name so that both sets of
> packages will exist in unstable at the same time. If you re-use ruby1.9
> with ruby1.9.1 binary package, the ruby1.9 will be removed.

I think that there are no new users of ruby1.9 (Ruby 1.9.0) packages.

When we re-use ruby1.9 for ruby1.9.x,
binary pakcges are removed from the archive.
But we still can keep ruby1.9 and ruby1.9.x in our system.

Should we provide some versions of Ruby 1.9 package at the same time?

> Ooops, it's "transition" as a verb, not as a noun.

sorry.

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 23/07/09 at 08:04 +0900, akira yamada / やまだあきら wrote:

> >>> Source package name
> >>> ruby1.9.1
> >> Why you switch source package name to "ruby1.9.1"?
> >
> > because you need to change the source package name so that both sets of
> > packages will exist in unstable at the same time. If you re-use ruby1.9
> > with ruby1.9.1 binary package, the ruby1.9 will be removed.
>
> I think that there are no new users of ruby1.9 (Ruby 1.9.0) packages.
>
> When we re-use ruby1.9 for ruby1.9.x,
> binary pakcges are removed from the archive.
> But we still can keep ruby1.9 and ruby1.9.x in our system.
>
> Should we provide some versions of Ruby 1.9 package at the same time?

My big problem with the re-use of the ruby1.9 source package is that
transitionning all packages will take time. We lack manpower in the
Debian/ruby community, and, without technical help from tools like
ruby-support, the transition is likely to take at least a month.

I don't want ruby to be in a broken state (uninstallable libs, etc) for
such a long time. Of course, users that still have 1.9.0 packages (and
prevent them from being upgraded to 1.9.1) would be fine, but if a user
upgrades it by mistake, and then discover that a library he needs is not
available with 1.9.1 yet, he will have to downgrade ruby.

That's why I really think that the only sane choice is to fully support
several ruby versions for some time, to leave more time for the
transition.

Also, note that the transition from 1.9.0 to 1.9.1 is relatively easy,
since most packages aren't available for 1.9.0 yet. But the 1.9.1->1.9.2
transition is likely to be even more painful.

Another problem is that by automatically upgrading to 1.9.1, you will
break stuff on the user's machine. Manually installed libs and gems that
were installed with 1.9.0 will no longer work with 1.9.1. That's why I
think that the switch to 1.9.1 must be made consciously by the user.

> > Ooops, it's "transition" as a verb, not as a noun.
>
> sorry.

My fault :-)
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Yasuhiro Araki-2]

Hi,

> Also, note that the transition from 1.9.0 to 1.9.1 is relatively easy,
> since most packages aren't available for 1.9.0 yet. But the 1.9.1->1.9.2
> transition is likely to be even more painful.

Disagree.
1.9.1 -> 1.9.2 transition is easier than 1.9.0->1.9.1.
Because ruby1.9.2 is binary compatible of 1.9.1.


> Another problem is that by automatically upgrading to 1.9.1, you will
> break stuff on the user's machine. Manually installed libs and gems that
> were installed with 1.9.0 will no longer work with 1.9.1. That's why I
> think that the switch to 1.9.1 must be made consciously by the user.

I propose to add some "alert information" at apt-get install.

araki


--
ARAKI Yasuhiro


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 23/07/09 at 10:55 +0900, Yasuhiro Araki wrote:
> Hi,
>
> > Also, note that the transition from 1.9.0 to 1.9.1 is relatively easy,
> > since most packages aren't available for 1.9.0 yet. But the 1.9.1->1.9.2
> > transition is likely to be even more painful.
>
> Disagree.
> 1.9.1 -> 1.9.2 transition is easier than 1.9.0->1.9.1.
> Because ruby1.9.2 is binary compatible of 1.9.1.

Is it 100% sure that 1.9.2 will be binary-compatible with 1.9.1?
Anyway, take the 1.9.2->1.9.3 transition if you prefer.

> > Another problem is that by automatically upgrading to 1.9.1, you will
> > break stuff on the user's machine. Manually installed libs and gems that
> > were installed with 1.9.0 will no longer work with 1.9.1. That's why I
> > think that the switch to 1.9.1 must be made consciously by the user.
>
> I propose to add some "alert information" at apt-get install.

Adding a layer of debconf warnings is not a nice Debian way to solve
that.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[akira yamada]

Hi,

On 2009/07/23, at 8:25, Lucas Nussbaum wrote:

> My big problem with the re-use of the ruby1.9 source package is that
> transitionning all packages will take time. We lack manpower in the
> Debian/ruby community, and, without technical help from tools like
> ruby-support, the transition is likely to take at least a month.
>
> I don't want ruby to be in a broken state (uninstallable libs, etc) for
> such a long time. Of course, users that still have 1.9.0 packages (and
> prevent them from being upgraded to 1.9.1) would be fine, but if a user
> upgrades it by mistake, and then discover that a library he needs is not
> available with 1.9.1 yet, he will have to downgrade ruby.
>
> That's why I really think that the only sane choice is to fully support
> several ruby versions for some time, to leave more time for the
> transition.
>
> Also, note that the transition from 1.9.0 to 1.9.1 is relatively easy,
> since most packages aren't available for 1.9.0 yet. But the 1.9.1->1.9.2
> transition is likely to be even more painful.
>
> Another problem is that by automatically upgrading to 1.9.1, you will
> break stuff on the user's machine. Manually installed libs and gems that
> were installed with 1.9.0 will no longer work with 1.9.1. That's why I
> think that the switch to 1.9.1 must be made consciously by the user.

I agree.

(But I think that we should further discuss
about ruby-support and new policy issues.
Daigo-san and I will forward comments from Japanese Debian users.)

I will do the following steps:

 1. ITP ruby1.9.1 (tomorrow)
 2. prepare ruby1.9.1.deb
 3. upload ruby1.9.1.deb to sid (maybe next week)
 4. ITP ruby1.9.1 (after above step)
 5. prepare ruby1.9.2-preview1.deb (ruby1.9.2_1.9.2~preview1)
 6. upload ruby1.9.2-preview1.deb to experimental

Any comments?

--
ay


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Lucas Nussbaum]

On 23/07/09 at 18:20 +0900, akira yamada wrote:

> Hi,
>
> On 2009/07/23, at 8:25, Lucas Nussbaum wrote:
> > My big problem with the re-use of the ruby1.9 source package is that
> > transitionning all packages will take time. We lack manpower in the
> > Debian/ruby community, and, without technical help from tools like
> > ruby-support, the transition is likely to take at least a month.
> >
> > I don't want ruby to be in a broken state (uninstallable libs, etc) for
> > such a long time. Of course, users that still have 1.9.0 packages (and
> > prevent them from being upgraded to 1.9.1) would be fine, but if a user
> > upgrades it by mistake, and then discover that a library he needs is not
> > available with 1.9.1 yet, he will have to downgrade ruby.
> >
> > That's why I really think that the only sane choice is to fully support
> > several ruby versions for some time, to leave more time for the
> > transition.
> >
> > Also, note that the transition from 1.9.0 to 1.9.1 is relatively easy,
> > since most packages aren't available for 1.9.0 yet. But the 1.9.1->1.9.2
> > transition is likely to be even more painful.
> >
> > Another problem is that by automatically upgrading to 1.9.1, you will
> > break stuff on the user's machine. Manually installed libs and gems that
> > were installed with 1.9.0 will no longer work with 1.9.1. That's why I
> > think that the switch to 1.9.1 must be made consciously by the user.
>
> I agree.

Thanks a lot for that!

> (But I think that we should further discuss
> about ruby-support and new policy issues.
> Daigo-san and I will forward comments from Japanese Debian users.)
>
> I will do the following steps:
>
>  1. ITP ruby1.9.1 (tomorrow)
>  2. prepare ruby1.9.1.deb
>  3. upload ruby1.9.1.deb to sid (maybe next week)
>  4. ITP ruby1.9.1 (after above step)

                  ^2?
>  5. prepare ruby1.9.2-preview1.deb (ruby1.9.2_1.9.2~preview1)
>  6. upload ruby1.9.2-preview1.deb to experimental
>
> Any comments?

No, that looks perfectly fine. I'll try to work on that too during
Debcamp/debconf (we can coordinate using svn), but will probably
concentrate on ruby-support. I'm aware that it's clearly not perfect
yet, and would very much appreciate feedback.
--
| Lucas Nussbaum
| lucas@...   http://www.lucas-nussbaum.net/ |
| jabber: lucas@...             GPG: 1024D/023B3F4F |


--
To UNSUBSCRIBE, email to debian-ruby-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...