\ay diary

ふと思いたって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寄りにシフトして、パッケージ内容の改善に取りくんだり、ある面でのパイプ役を目指すという選択もありそうだ。そうしていこうかな?

C言語のワンライナーを書くためのCというツールがある、というのをついさっき知った。

普段C言語を何かを作るということはあまりなくて、C言語といえばどちらかというと読むもの。しかも部分的に。だから「あれ、どうだったかな?」なんていうのは――「;」忘れも欠かさない私にとってはよくあること。意外と使えるかもしれない。

こういうツールで迷うのはどこにインストールするか。ちょっと使ってみるだけになるかも、と思うと/usr/localを使うのは…… という気分になる。かといってホームディレクトリにポンと置いておくだけというのも。

まあ、本当のところは迷ってはいない。ちょこちょこっとパッケージングしてしまえばいいのだ。特にこういう小さくて、サーバ的でもないツールならパッケージ化の手間もたいしたことはない。

具体的な手順はこんなところ。

$ tar xf C-0.06.tar.gz
$ cd C-0.06
$ dh_make -c gpl2 -b -s -p large-c -f ../C-0.06.tar.gz
$ cd debian
$ rm README.* cron.d.ex emacsen-* init.d.* large-c.* manpage.* menu.ex post* pre*
$ vim copyright
$ vim control
$ mv watch.ex watch
$ vim watch
$ cd ..
$ debuild -uc -us

debian/copyrightやdebian/controlはREADMEなどからのコピー&ペーストで、debian/watchもURLを調整する程度。C-0.06のような構成ならdebian/rulesに手をいれる必要もない。

実際にはlintianエラーをつぶすためにdebuildをあと二回くらいは実行したものの、全工程で15分ほど。できたlarge-c_0.06-1_i386.debをインストールして作業を終えた。

$ C -cWall -cO2 -e 'printf("hello world\n")'
hello world

「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パッケージの構成変更案

	現在の内容	変更新の内容
ruby	/usr/bin/rubyを提供 ruby1.8に依存	/usr/bin/ruby*を提供しない 各時点での最新Rubyパッケージのどれかに依存(*1)
ruby1.8	/usr/bin/ruby1.8を提供 alternativesなし	/usr/bin/ruby1.8を提供(変更なし) /usr/bin/rubyへのalternativesを登録
ruby1.9	/usr/bin/ruby1.9を提供 alternativesなし	/usr/bin/ruby1.9.0を提供 /usr/bin/ruby1.9と/usr/bin/rubyへのalternativesを登録
ruby1.9.1	/usr/bin/ruby1.9.1を提供 alternativesなし	/usr/bin/ruby1.9.1を提供(変更なし) /usr/bin/ruby1.9と/usr/bin/rubyへのalternativesを登録

 (*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-」といったインタプリタへのsymlinkも提供し、これをパッケージングに使えるようにしてはどうだろうかと考えている(これ自体はalternativesにそぐわないと思うので、どういった形で提供するのか悩ましいが)。

@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を使って知らせてもらえるとありがたい。直接声をかけてもらうのでもいいけれど。どうしても取捨選択することにはなるけれど、リーズナブルなものについては努力するつもり。

ruby1.9.1パッケージがDebian/sidに入った。いくつか考え込んでいるうちに作業を進めてもらってしまうことになってしまい、実質的に何もお手伝いできなかった。いくつか必要そうなパッチが出ているように思うので、そちらで協力していくのと、ruby1.9.2パッケージの準備のほうで、今度こそ貢献できるようにと考えている。

さて、ruby1.9.1パッケージの登場によりDebian/sidでも(ようやく)手軽にRuby 1.9.1を使えるようになった。とはいえ、DebianのRubyパッケージはいくつかのサブパッケージに分割され提供されている。そのためフルセットの環境を構築するのはめんどくさい…… と思われがちである。しかしながら、いまどきのaptitudeを使えば以下のコマンドラインで一括してインストールが可能だ。もうruby1.9.1-fullなんていうパッケージはいらない。

$ sudo aptitude install '?source-package(^ruby1\.9\.1$)'

ちなみにruby1.9.1-elispパッケージを除くなら以下のようになる。

$ sudo aptitude install '?source-package(^ruby1\.9\.1$)!~n^ruby1\.9\.1-elisp$'

もちろんaptitudeの検索式はいろいろなところで使える。aptitude searchならリストアップが可能だし、aptitude removeやaptitude purgeに使えばまとめて削除ができる。ぱぱっとソラで書けるかというとそうでもなくて、ちょっと手間取りそうな記述ではある。ただ、そういうことができるということを覚えておくと何かのときに役立つだろう。

ruby*-fullのような依存関係を提供するメタパッケージはある面で便利なのはわかる。ただ柔軟性はまったくないので使える場面はかなり限られると思う。実際のところ最初のインストールのときだけあれば十分だという人が多いのではないだろうか(もっというなら、インストール後は自動的に消えてくれと思う人だっているだろう)。その点、上に書いたような方法であれば(あるいはgrep-dctrlを使うような方法であれば)応用が効いて使いでがあるはずだ。

昨日の帰りみちでの思い付きだけど、わりとピンときているのでこのあたりでやってみようかなと考えている。おそらく横浜近辺にて開催。参加見込みがまったくわからないので、興味があるという人がいたらコメントなどもらえるとうれしいです(twitterやfriendfeedでも)。

五人くらい集まるようならやってみよう。(五人くらいなら、どっかのカフェでってのもよいかな。)

Capistrano勉強会「deploy.rbを読む夕べ」

• 目標
  • タスクを書けるようになる(その足掛かりをつかまえる)
• 開催日時
  • 未定(7/下〜8/中くらい?)
  • 二時間程度
• 前提知識
  • スクリプト言語の経験 - Perl、PHP、など(もちろんRubyでも)
  • ある程度のUNIX知識(シェルの利用方法など)

Rails向けに提供されているdeploy.rbをいっしょに読んでタスクの構造を学ぶ。実際に使われているタスクの実装を読み解くことによりSSHフレームワークとしてのCapistranoの姿をとらえ、その(Rails以外での)活用方法を知る。

CapistranoでRubyを始めてもいいんじゃない?

Debian勉強会「パッケージを作ろう」

• 目標
  • 自分でパッケージを作れるようになる
  • 既存パッケージをカスタマイズできるようになる
• 開催日時
  • 未定(9月くらい?)
  • 二〜三時間程度
• 前提知識
  • Debian/Ubuntuでのパッケージ操作経験(aptitude/apt-getによるインストールや削除など)
  • ソフトウェア構築の経験(configure; make installなど)

経続的なメンテナンスが可能なパッケージ作りを考える。パッケージ間の関係性やポリシーの役割りに注目し、長く使える、どこでも使えるパッケージを目指す。

またパッケージ作りの流儀を概観し、既存パッケージのカスタマイズ方法を知る。

この前の日曜日、Debain Ruby 1.9会議を無事に開催することができました。

最終的な参加人数は10人。三時間みっちりと議論を行えました。当初の予定を大きく越えて、なかなかに深い話ができたと思います。あまり単純化して考えてもいけないかもしれませんが、人が集まるというのは得るものがたくさんあります。

実のところ、参加した人々に満足してもらえるような話題を用意できるのかかなり不安でした。そもそもがごく奥まった狭いところにしぼった集まりあったわけで、参加する人には何らかの期待があるとして、 それに応えられないのでないかと思っていました。しかしやってみればそんなことはなく、考えいたよりもスムーズに、かつ広がりを持ちつつ議論を進められました。意見交換ができればまずは十分、なんて言いながら始めたのが信じられないくらいです。

議論そのものがよい感じで進んだのはもちろんですが、 ToDoがいくつか出来たのはよかったです。Ruby開者のcoreチームから参加していただけたのもずいぶんと話を進められた要因だと思います。 Debianパッケージメンテナンス的にはかなり重要な情報もいただけました。

今回の内容はなるべく早いうちに何かの形にまとめる予定です。もちろん手を動かしていくこともします。

というところでちょっと反省点を。

石川町駅からの会場への道順の説明で「川があるから〜」と書いていたのですが、実際に歩いてみると大通りがあって川なんて見られませんでした。気付いたのは当日。なまじ地図が頭に入っていたせいで失敗しました。気を付けねばなりません。

しゃべっている間のメモ取りは難しいです。 録音しようかどうしかう迷って、 結局は録音しませんでした。でも、したほうがよかったかも。ああしよう、こうしよう、というのもあったのですが、なかなか思う通りには。

最後に、参加されたみなさまおつかれさまでした。 そしてありがとうございました。 まとめ作業などでもう少しお付き合いいただくことがあるかと思いますが、どうぞご協力ください。また、個人的にはパッケージメンナンス作業に対して弱気になることがままあるのですが、今回、いろいろな話を聞くことができかなりはげみになりました。

(蛇足: 事前に最も不安に思っていたのは、実は茶菓子だったりします。甘いものが苦手な人やコーヒーを好まれない人もいるかもしれないし…… そもそも好みに合うものやらどうやら…… などなど。幸いおおむね気にいっていただけたようで、ほっとしています。)

リンク

• Debian Ruby 1.9 会議に参加してきた
• debian ruby at 横浜

先日お知らせしたDebian Ruby1.9会議の開催日時と場所が以下に決まりました。

• 日時: 2009-07-05(日) 14:00〜17:00
• 場所: かながわ労働プラザ 第10会議室

参加される方へのお願い

参加される方との連絡・情報交換のためにGoogleグループに場を設けています。ATNDで参加登録された方は、私(akira.yamada gmail.com)まで以下の二点をお知らせください。

• 登録するメールアドレス
• ATNDでのユーザ名

今月のSoftware Design(2009/7号)はDebian特集であった。パラパラとながめていって、ふとパッケージ情報にアクセスするツールを調べ直したくなった。

といっても--helpしてみたり、manページを見たりといった程度。そんな中、grep-dctrlに便利な機能が加わっているのに気付いた(etchのころにはもうあったようだが気付いていなかった、とも言える)。その機能というのは-Sオプション。-Sオプションは-F Source:Packageの短縮形で、パッケージ情報にSourceフィールドがあればそれに対して、なければPackageフィールドに対してパターンマッチを行う。

各バイナリパッケージのパッケージ情報には、そのバイナリパッケージを作るもととなったソースパッケージが何であるかが含まれいることがある。一つのソースパッケージから複数のバイナリパッケージが生成されることがあるためで、ソースパッケージ名とバイナリパッケージ名が異なる場合にSourceフィールドが現れ、その値としてソースパッケージ名が記述される。

あるソースパッケージから生成されるすべてバイナリパッケージを探し出したいとするとき-Sオプションが便利だ。たとえば、ソースパッケージruby1.8から生成される、つまり、パッケージとして提供されるRuby 1.8の全部をインストールしたいとすると、次のようなコマンドラインが考えられる。

$ grep-aptavail -n -X -s Package -S ruby1.8 | xargs sudo aptitude install

(しばし余談)

ここで、-Sオプションではなく、-F Source,Packageでも実現できるのではないかと思える。「:」でなく「,」で区切った場合、そのうちのどれかにマッチしたものが出力されるからだ。だが、実際にやってみるとこれはうまくいかない。なぜかというと、あるソースパッケージの名前と同じ名前のバイナリパッケージを生成する別のソースパッケージというのが存在する可能性があるのだ。

$ grep-aptavail -X -s Package,Source -S libqt4-ruby
Package: libsmokeqt4-1
Source: libqt4-ruby

Package: libsmokeqt4-dev
Source: libqt4-ruby

$ grep-aptavail -X -s Package,Source -F Source,Package libqt4-ruby
Package: libsmokeqt4-1
Source: libqt4-ruby

Package: libsmokeqt4-dev
Source: libqt4-ruby

Package: libqt4-ruby
Source: kdebindings

libqt4-rubyは一例で他にもいくつかある。このような状態はリリース間でパッケージ構成が変わったなど、特別なケースであることが多いと思うが、そういうこともありうるという点には気を付けておいたほうがよいだろう。

(本題に戻る)

sarge以降(あえてsargeという :-)、apt-getではなくaptitudeが用いられていることと思うが、最近のaptitudeの検索パターンは実に充実していることにも気付いた。ソースパッケージruby1.8から生成されたパッケージを選び出してインストールしたければ、次のようにコマンド実行すればよい。

# aptitude install '?source-package(^ruby1\.8$)'

きたる2009-07-05(日)にDebian Ruby1.9会議を開催することになりました。Debianにおける主要なRubyパッケージ開発者のうちの実に二名が参加することが決定しています…… とか言っても、お気付きの通り、そのうちの一人は私です。

今回の開催はRubyパッケージやRubyGemsのパッケージの開発者であるdaigoさんから声をかけていただいたのがきっかけです。現在、構成変更などの議論を進めている関係で、Debian/sidにおけるRuby 1.9のパッケージのリリースが遅れています。その状況を改めて確認し、解決しなければならないことや決定しなければならいことを話し合い、物事を先に進めていこうというのが主旨です。

かなり奥まったところにある話題なので、興味を持つ人は限られるかもしれませんが、話を聞いてみたい、意見がある、パッケージ開発者を見てみたい、といった方がおられましたらご参加ください。Debian Ruby1.9会議の参加登録はATNDで受け付けています。

開催地は川崎〜横浜のどこかになることが決定しています。ただし具体的な会場などは未定で、二人以外の参加者がどれくらいあるかに応じて会場を確保したいと考えています。

私個人としては、参加者がある程度集まって、時間に余裕があるようなら、おまけ的にRuby on Debian談義をするのも悪くないかなと思っていますが、これは単に思い付きレベルの話で未定です。(それにしても奥まった話題のような気もしますが。)