Feature #5314: パッケージマネージャをコアリリースに含めて欲しい

• Status: Third Party's Issue
• Assignee: -
• Target version: -

[kaoriya (Taro MURAOKA)]

Rubyは素晴らしいパッケージ(ライブラリ)が多いことが魅力の一つです。
その良さの維持には優れたパッケージマネージャが欠かせません。

しかしながら過去には代表的なパッケージマネージャ自身が
バージョンアップに伴い互換性を欠くという問題を起こしたケースがあり、
これではその魅力が損なわれてしまいます。

よって今後そうならないように、コアリリースに安定したパッケージマネージャを含め、
リリース期間中はその安定性を堅持することを提案いたします。

[shyouhei (Shyouhei Urabe)]

• Status changed from Open to Feedback

Taro MURAOKA wrote:

しかしながら過去には代表的なパッケージマネージャ自身が
バージョンアップに伴い互換性を欠くという問題を起こしたケースがあり、
これではその魅力が損なわれてしまいます。

すいませんどの話でしたでしょうか? さすがに漠然としすぎていて何とも言えなさすぎます。もう少し具体的に。

[usa (Usaku NAKAMURA)]

Ruby 1.9には現在1.9.1および1.9.2という2つのバージョン系列が存在して
それぞれ保守されている(ことになっている)のですが、いずれにもrubygemsという
rubygemsというパッケージマネージャが同梱されていて、1.9.1の場合は
rubygems 1.3.1というバージョンが、1.9.2の場合は1.3.7というバージョンが、
それぞれ最初のリリースから現在までずっと維持されています。

これじゃ不満ってことでしょうか？

[kaoriya (Taro MURAOKA)]

http://www.kaoriya.net/blog/201109/20110913

ネタ元としてはココで書いたように私の体験に基づいてまして、まったくRubyのせいではないのですが、
ruby-gemsが1.7から1.8に上がった際に、それに強く依存したrails 2.3.11を含むredmine 1.2.1が動かなくなる
という事象に遭遇しています。

重要なのは私の問題を解決することではなく、こういうことが今後起こらないようにするにはという点です

いろいろと話を伺ったところ1.9以降gemsはコアリリースとの統合が進んでいるようなことを耳にしました。
また優先順位の問題でパッケージマネージャのリリースマネージメントは手がつかないかもとも聞きました。

パッケージマネージャとコアが密接にリリースマネージメントされていれば
私のように不幸な事象に遭遇する確率は将来的に格段に下がり、
なおかつrubyの言語としての魅力が一層際立つと考え提案した次第です。

[kaoriya (Taro MURAOKA)]

Usaku NAKAMURA wrote:

Ruby 1.9には現在1.9.1および1.9.2という2つのバージョン系列が存在して
それぞれ保守されている(ことになっている)のですが、いずれにもrubygemsという
rubygemsというパッケージマネージャが同梱されていて、1.9.1の場合は
rubygems 1.3.1というバージョンが、1.9.2の場合は1.3.7というバージョンが、
それぞれ最初のリリースから現在までずっと維持されています。

これじゃ不満ってことでしょうか？

おおよそ満足なんですが話に聞くところだと

http://twitter.com/#!/mrkn/status/113504956631359488

rubygems側のバージョンアップに伴うリリースマネージメントが難しそうな印象を持ち
かつ報告しなければどうにも動かんよとのことだったので

http://twitter.com/#!/mrkn/status/113526845663756289

とりあえずは報告したという次第です。

[shyouhei (Shyouhei Urabe)]

• Status changed from Feedback to Third Party's Issue

お気持ちは察するものの、portsで入れたredmineが動かなくなった件で責められるべきなのはportsかなあと思います。

rubygemsにはrubygemsの流儀があるわけです。rubygemsにおいて後方互換性が問題にならないのは、長所でもある。その流儀は、portsの流儀とは違うのでしょう。portsはよく知りませんが、rubygemsを抱え込む決断をしたのなら、rubygemsを「乗りこなしてみせる」必要があるんじゃないかなあ。

[sorah (Sorah Fukumori)]

Shyouhei Urabe wrote:

お気持ちは察するものの、portsで入れたredmineが動かなくなった件で責められるべきなのはportsかなあと思います。

rubygemsにはrubygemsの流儀があるわけです。rubygemsにおいて後方互換性が問題にならないのは、長所でもある。その流儀は、portsの流儀とは違うのでしょう。portsはよく知りませんが、rubygemsを抱え込む決断をしたのなら、rubygemsを「乗りこなしてみせる」必要があるんじゃないかなあ。

はい．同意見です．
Rubyコアチームが新たにパッケージマネージャを開発するにしても
Rubygemsが現在メジャーになってるわけですし，
rubygemsじゃないのを新たに開発したりするのはどうなんだかなあ，そこに人的リソースを割くメリットはあるのかなあ，
ってかんじです．

rubygemsはややこしい．．．
OSのパッケージマネージャーとの親和性は結構重要だったりするんだろうか?
(あまり困ってないからわからないのですが，複数サーバーをまとめて管理するときとかにラク?)

[taca (Takahiro Kambe)]

少しだけ書きます。

In message [e-mail]
on Tue, 13 Sep 2011 18:24:39 +0900,
Taro MURAOKA [e-mail] wrote:

Issue #5314 has been updated by Taro MURAOKA.

http://www.kaoriya.net/blog/201109/20110913

ネタ元としてはココで書いたように私の体験に基づいてまして、まったくRubyのせいではないのですが、
(...snip...)
そもそも独自のパッケージシステム的な側面を持つ rubygems と、
(おそらく)portsや(間違いなく)pkgsrcのような、いわば汎用的な
パッケージシステムとの相性はよろしくないと考えています。

(おそらく)portsや(間違いなく)pkgsrcでは、複数のバージョンの
パッケージをインストールするといったこと自体、パッケージを
作成する側に負担が大きい面があります。この点はバージョンに
関係なく放り込めるrubygemsとの距離が大きいです。

また、いずれもインストールするファイルの管理といった側面で
は二重の作業的な部分もあります。(それにどのように対処してい
るかは、portsとpkgsrcでも違うことでしょう。)

このような根本的な衝突する部分があるため、

パッケージマネージャとコアが密接にリリースマネージメントされていれば
私のように不幸な事象に遭遇する確率は将来的に格段に下がり、
パッケージマネージャーがどのようなものを想定されているかま
で今一つ私は理解できていないか気もしますが、管理するツール
の対応だけで何とかできるものもない気がします。

なお、ネタ元の問題ですが、redmineのportsはruby-gems 1.8以上
のバージョンとは conflict するといった指定にすべきところなの
でしょう。(結果的に、redmineのportsを作成できなくなりますが、
ネタ元のようなカタストロフィは避けられたかもしれません。また、
portsで依存するパッケージのバージョンの範囲の上限も指定でき
たかどうか確認もしていません。)

また、何かパッケージマネージャー的なものが導入されるにしても、
外部のパッケージシステムと親和性が高い方向に持って行くことを
希望します。(Unlike python...)

以上です。(少しだけにならなかったか...。)

--
神戸 隆博 (かんべ たかひろ) at 仕事場

[usa (Usaku NAKAMURA)]

こんにちは、なかむら(う)です。

In message "[ruby-dev:44495] [Ruby 1.9 - Feature #5314] パッケージマネージャをコアリリースに含めて欲しい"
on Sep.13,2011 18:30:14, [e-mail] wrote:

おおよそ満足なんですが話に聞くところだと

http://twitter.com/#!/mrkn/status/113504956631359488

rubygems側のバージョンアップに伴うリリースマネージメントが難しそうな印象を持ち
かつ報告しなければどうにも動かんよとのことだったので

http://twitter.com/#!/mrkn/status/113526845663756289

とりあえずは報告したという次第です。

ああ、なるほど。ありがとうございます。

基本的に、一旦あるバージョンのRuby(例えば1.9.2)がリリースされ
ると、その後は時々いくつかの問題を修正した1.9.2-p100とか1.9.2
-p250とか、そういう感じで後ろに-pXXXというものがくっついたRuby
がリリースされます。
で、この1.9.2-pXXXの間は、同梱されるrubygemsのバージョンは変
化しないはずなので、意図せざるバグの混入以外では非互換は発生
しないはずです。

mrknさんはコミッタなので開発の先っちょのことを言っておられる
わけですが、実際のリリースが行われない限り一般ユーザーにとっ
ては無縁のどうでもいい世界の話でして、困るのはコミッタとごく
少数の奇特なヒトバシラーだけのはずです。
この人たちは自ら望んで好んでこの手の苦労(なのかなあ?)をしょい
こんでるはずなので、愚痴っぽいことを言っていたとしても実際は
ニヤニヤしてるはずです :)

それでは。

U.Nakamura [e-mail]

[naruse (Yui NARUSE)]

意外と事実関係が複雑なのでまずまとめますと、

ports の元の状態はこうでした。

• lang/ruby18 (1.8.7)
• devel/ruby-gems (1.7.1 or 1.7.2)
• www/redmine
  で、Rails は 2.3.11 が www/redmine に同梱されていました。

で、最近 /usr/local/bin/ruby の座が 1.9 に明け渡されたり、www/rubygems-rails が 3 になったりしてるんですがそれは関係なくて、
devel/rubygems が 1.8.7 になったことが原因です。

RubyGems では 1.8.5 において互換性を破壊する変更がなされており、件の Rails 2.3.11 が動かなくなりました。
http://blog.majesticseacreature.com/summary-of-rubygems-18-breakage-reports
なお、これは Rails 等 gems のユーザ側が追従しています。

これによって redmine も影響を受けて動かなくなったというのが今回の問題です。
（なので、パッケージマネージャ同士の衝突は今回あんまり問題ではなく、単純にライブラリとしての RubyGems の問題）

わたしが思うに今回の件で改善すべきものがあるとすれば、

• ports の www/redmine は devel/ruby-gems に依存する必要がある
• www/redmine 同梱の rails を 2.3.14 に上げる
• RubyGems は 1.8.5 みたいな中途半端なバージョンで非互換の変更を入れるな
  あたりですかね。

一方で、村岡さんのおっしゃる「パッケージマネージャとコアが密接にリリースマネージメントされていれば」というのは、
ちょっと問題がありまして、Ruby のリリースは1年~2年に一度なのです。
これはリソースが足りないという以外に、

• リリースごとに互換性がすこしずつ壊れるのでブランチのメンテがどちらにしろ必要
• ブランチのメンテではバグ修正以外はしない
  というポリシーの違いに起因している面も大きいので、やっぱりレイヤーが違うんじゃないかなぁと思いますね。

ま、根源的な問題として、RubyGems はパッケージマネージャのくせに頻繁にバージョンアップしすぎなんですよ（ぉぃ

[taca (Takahiro Kambe)]

In message [e-mail]
on Tue, 13 Sep 2011 18:49:18 +0900,
Shota Fukumori [e-mail] wrote:

rubygemsはややこしい．．．
同感。

OSのパッケージマネージャーとの親和性は結構重要だったりするんだろうか?
(あまり困ってないからわからないのですが，複数サーバーをまとめて管理す
るときとかにラク?)
少なくともバイナリパッケージを使えば、コンパイラのないマシンにも
さくっとインストールできます。(もちろん、コンパイル済みのバイナ
リを含んだgemを作ればいいですが、多くのOSに対応したい場合はなか
なか難しい面もあるでしょう。)

--
神戸 隆博 / Takahiro Kambe

[sorah (Sorah Fukumori)]

sora_hです．

2011/9/13 Takahiro Kambe [e-mail]:

少なくともバイナリパッケージを使えば、コンパイラのないマシンにも
さくっとインストールできます。(もちろん、コンパイル済みのバイナ
リを含んだgemを作ればいいですが、多くのOSに対応したい場合はなか
なか難しい面もあるでしょう。)

あー，なるほど．それは確かに

--
Shota Fukumori a.k.a. @sora_h - http://sorah.jp/

[kaoriya (Taro MURAOKA)]

ココまでの説明だとなかむら(う)さんの
「リリースでは今後は(パッケージマネージャ絡みの)問題は起こらんから安心しろ」
が一番納得がいきます。

私も最初は聞かされた時はそうなるもんだと思いましたから

ただcommitterの方からそうではないんだよという話と、
チケットに残さないと忘れられるだけだよという指摘をいただいたので
こちらで提案したのです。

ま、根源的な問題として、RubyGems はパッケージマネージャのくせに頻繁にバージョンアップしすぎなんですよ（ぉぃ

だったら首根っこ押さえちゃえば良いじゃん、と思いましたw

バイナリ配布という視点では、
MacOSXとWindows版があれば大方のユーザはカバーできそうですが。

ていうか昔、Ruby公式がそれらのバイナリ配ってなくて困った記憶があります