DebianとRubyと私
ふと思いたってDebianにおけるRubyの状況を調べてみた。といってもpopularity-contestによる集計結果を見てみただけである。
実際に見てみるとlibruby1.8で25,000ホストほど、ruby1.8で7,000ホストほど、それぞれ利用されているらしいことがわかる。2007年に入るあたりからの急激なカーブはRailsの影響なのだろう。
popularity-contestのデータに対する割り合いのほうで見ると、libruby1.8で25%くらい、ruby1.8で10%くらいとなっている。ごく楽観的にとらえれば、その程度の割り合いで各パッケージが利用されている…… かもしれない、くらいは言ってもいいだろうか。もっとも、popularity-contestというのは自己申告のようなものだから、そもそも実情をうまく表していない可能性がある。まあ、実情とまるで違うということもないだろうと思うが。
ともあれ、Debian Projectにイキオイだけで参加した際の目的は、DebianでRubyを使えるようにすることだった。そこから考えてみると、いろいろありはしたものの、ある程度、成果みたいなものを作ってこられたのかなと思う。
もちろん一人でやってきたわけではなくて、初期にはいろいろな人からサポートしてもらったし、その後もわからないことがあるたびに(MLやIRCで)いろんな人にいろんな面で助けてもらった。さらにはukaiさん、tagohさんに比較的早い時期からメンテナンスを手伝っていただいた。また数年前からはdaigoさん、lucasさんがメンテナンスに参加してくれて、今では私よりもむしろお二人の活動に支えられている。
個人的には今後どうするか、を考え始めてしばらくたっている。姿勢を迷ってしまうことがあり、パッケージデザインは私個人の手を離れている。これまではパッケージをどういう形で提供するかを主要な問題としてきた。それよりはRuby寄りにシフトして、パッケージ内容の改善に取りくんだり、ある面でのパイプ役を目指すという選択もありそうだ。そうしていこうかな?
Debianのruby*パッケージとalternatives
「Bug#548917: Please use alternatives system to manage the ruby symlink」という要望を受けて、しばらく前から考えていたことを投げてみた。これまでrubyパッケージは「/usr/bin/ruby」によって「Debianの標準Ruby」を提供してきた。これを止めてはどうかという提案である。
「/usr/bin/ruby」はDebianにおいて、Ruby関係の安定したパッケージングのために必要と考えられてきたものだが、Ruby 1.8.xしかなかったこれまではそれほど目立つものではなかったようにも思う。ところがRuby 1.9.xの時代になり、バージョン間の互換性に注意が向くようになった。そのおかげで互換性レベルが作られた。加えて、JRubyなどの別実装のRubyがいくつも開発され、パッケージとしても提供されてきている。
ここにきて問題なのは標準のRubyというものが決められないのではないかということ。ごく個人的にはMRIがそうだとは思うのだが、仮にそう言ってしまってかまわないとしても、それは1.8なのか1.9.1/1.9.2なのか。Ruby 1.9.5あたりがリリースされたころにはどうなるのか。もっといえば1.8でも1.8.6なのか1.8.7なのかという人だっているかもしれない。
こうなると決めるのは無理なので「/usr/bin/ruby」をalternativesにしてしまってはどうか考え始めていた。同様に「/usr/bin/ruby1.9」についてもalternativesとする。ただし「/usr/bin/ruby1.8」はこれまで通り。この案を実施するには以下のような変更が必要となる(jruby*の様子はよく知らないので触れていない)。
| 現在の内容 | 変更新の内容 | |
|---|---|---|
| ruby |
/usr/bin/rubyを提供 |
/usr/bin/ruby*を提供しない |
| ruby1.8 |
/usr/bin/ruby1.8を提供 |
/usr/bin/ruby1.8を提供(変更なし) |
| ruby1.9 |
/usr/bin/ruby1.9を提供 |
/usr/bin/ruby1.9.0を提供 |
| ruby1.9.1 |
/usr/bin/ruby1.9.1を提供 |
/usr/bin/ruby1.9.1を提供(変更なし) |
(*1)については今のtestingなら「Depends: ruby1.9.1 | ruby1.8 | jruby1.1」のようなものを考えている。Ruby 1.9.2がリリースされたら「Depends: ruby1.9.2 | ruby1.8 | jruby1.1」のようになる(そのころにはruby1.8は抜けるかもしれない)。
lenny→squeezeなどの移行についてはおそらく問題ないのではないかと思う。実際にやってみないとわからないが。rubyパッケージをインストールしていたとすると、新たにruby1.9.1パッケージが加わるが、それによりruby1.9パッケージがなくなるわけではない。/usr/bin/ruby1.9へのalternativesの優先度が難しいが…… postinstでがんばるか、パッケージ的に妥協するかだろうか。
最初に触れた通り、これまでパッケージ作りにおいて「/usr/bin/ruby」を一般的なパスとして使うことができたが、この案を実施するとそうもいかなくなる。特定のRubyインタプリタを指定するのが推奨される。十分にメンテナンスが可能だとした上で「/usr/bin/ruby」を使うこともできなくはないが、よほど小さなパッケージでなければ難しいだろう。
ただ、そうはいうものの、Ruby 1.9.xについては互換性レベルがあるわけで、これをうまくすくいとりたいという思いもある。そこでパス名が適当かどうかはともかくとして「/usr/bin/ruby-compat-
Ruby 1.9.2の延期とDebian/squeeze
@takahashimさんによればRuby 1.9.2はRubySpecオールグリーンにしてからリリースすることに。そのためリリーススケジュール見直しへ
とのこと(ruby-core:25707)。
Debianの次期リリース(squeeze)には1.9.2が入るといいなと思いつつ、でもリリースのタイミングからいって難しいだろうなと考えいたが、このスケジュール見直しで1.9.2の線はなくなったといえる。ある意味わかりやすくなった。
一方で、Ruby 1.9.1にバグが見付かった場合のことを考えなくてはならなくなった。あまり独自にパッチをあててしまうと後で困るとはいえ、影響の大きなものには対処していきたいところ。たとえば、Regexpの「\d」の解釈の変化のようなものは必要に違いないと考え、Debianパッケージではパッチを用意している(リリースはこれから)。
他にも何かあるかもしれないし、これから出てくるかもしれない。対処が必要そうな修正や変更があったらBTSを使って知らせてもらえるとありがたい。直接声をかけてもらうのでもいいけれど。どうしても取捨選択することにはなるけれど、リーズナブルなものについては努力するつもり。
新しいPGP鍵
Debian Ruby1.9会議で署名してもらったばかりなのだけど新しいPGPの鍵を作った(0x4F88A881)。Ruby会議2009でもう一度お願いにまわります。
新しくしようと思ったのは期限を付けたかったため。五年くらいたてば何かと変わっているかな、なんて。
