[#31927] Re: Problem with Ruby 1.8.6-p110 on DragonFly (was [PATCH] Problem with ruby 1.8.6-p36 (and p39) on Tiger) — Takahiro Kambe <taca@...>
こんばんは。
[#31928] securerandom.rb for 1.8 — Tanaka Akira <akr@...>
securerandom.rb を 1.8 に追加し、cgi/session.rb に使わせたい
At Wed, 3 Oct 2007 12:49:20 +0900,
In article <86k5pwinco.knu@iDaemons.org>,
-----BEGIN PGP SIGNED MESSAGE-----
まつもと ゆきひろです
-----BEGIN PGP SIGNED MESSAGE-----
まつもと ゆきひろです
-----BEGIN PGP SIGNED MESSAGE-----
[#31936] Rake添付 — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
-----BEGIN PGP SIGNED MESSAGE-----
まつもと ゆきひろです
Yukihiro Matsumoto さんは書きました:
-----BEGIN PGP SIGNED MESSAGE-----
NAKAMURA, Hiroshi さんは書きました:
At Wed, 10 Oct 2007 16:46:01 +0900,
-----BEGIN PGP SIGNED MESSAGE-----
[#31941] Re: [ruby-list:44071] Re: Ruby 1.8.6-p111 / 1.8.5-p114 released (Security Fix) — Shugo Maeda <shugo@...>
前田です。
-----BEGIN PGP SIGNED MESSAGE-----
前田です。
-----BEGIN PGP SIGNED MESSAGE-----
前田です。
In message <47063403.3070402@ruby-lang.org>,
In message <20071006.101915.596518898.gotoyuzo@sawara.priv.tokyo.netlab.jp>,
前田です。
In message <4709852A.1020606@ruby-lang.org>,
-----BEGIN PGP SIGNED MESSAGE-----
In message <470D9227.9090008@sarion.co.jp>,
-----BEGIN PGP SIGNED MESSAGE-----
[#31959] pcc: constant too big for cross-compiler — "NARUSE, Yui" <naruse@...>
成瀬です。
In article <470884D1.9040401@airemix.com>,
[#31980] multibyte string/regex literal with escape sequence — "U.Nakamura" <usa@...>
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
まつもと ゆきひろです
こんにちは、なかむら(う)です。
まつもと ゆきひろです
成瀬です。
こんにちは、なかむら(う)です。
In article <20071010091006.1988.USA@garbagecollect.jp>,
成瀬です。
In article <471003CB.7060701@airemix.com>,
成瀬です。
[#32049] Re: iconv enhancement in Ruby 1.9 — Nobuyoshi Nakada <nobu@...>
なかだです。
[#32133] undefined method `now' for DateTime:Class (NoMethodError) — "NAKAMURA, Hiroshi" <nakahiro@...>
-----BEGIN PGP SIGNED MESSAGE-----
どういう状況かよくわかってないのですが、いっそ必ず date 丸ごと読むようにするか、
-----BEGIN PGP SIGNED MESSAGE-----
> もしかして、単にtime.rbの「require 'parsedate'」を削ればいいだけだったり
-----BEGIN PGP SIGNED MESSAGE-----
> 確かに。で、1.9でparsedate.rbがなくなることを考えると、とりあえずtime.rb
In article <4b1598ce0710231835p1a0b3040kcc89bf0017a60c21@mail.gmail.com>,
[ruby-dev:32122] Re: Import RubyGems to Ruby 1.9
oshida@bb-next.net さんは書きました: >> について、Ruby本体に添付されるライブラリがpre-installed-gem化されない場 >> 合、やまだあきらさんの懸念は払拭されるということになりますか? > > 「パッケージマネージャとの相性に関する懸念」については「yes」という前提とすると、 > (私にはやまださんの返信 32110 はそのように読めました。) パッケージの問題とは切り分けたつもりなんです。 >> どなたかこの辺、問題点と考察を箇条書きにまとめられないもんでしょうか。 > > 上記は(パッケージマネージャ視点、現行機能を拡張しない前提) > > ・gem がパッケージ外のファイルを置くことは我慢できる(問題ではない) > ・gem がパッケージ内のファイルを置換することには耐性を保証できない > > なので、後者を誘発するパッケージ内容を強要(前提)されると困る。 パッケージシステムを前提としているわけではなくて、 単にpre-installed-gemというものにメリットが見出せないと思っています (いや、メリットはあるという立場があるのは分かりますが)。 で、以下はパッケージシステムの機能についての話で あまり本論とは関係ないんじゃないかと思いますが…… # このあたりの話は、パッケージシステムがどう動くかとか # どうやるとパッケージを作れるかだけではなくて、 # どういうパッケージを作るべきかということも関係してきますし、 # 繰り返しですが本論とはあまり関係ないと思います。 > 「強要(前提)」とはソースに同梱され make 成果物に入っていること、です。 > RubyGems 本体や pre-installed gem 等が、です。 > > 「困る」は「努力すれば回避できるが基本的には控えて欲しい」ですかね。 > > 「回避できる」は、 > 例えば Red Hat 系は1つのソースから複数の rpm を作る事をわざわざするので、 > その延長で対処可能ではないか、 > との推測によります。 > Ruby の場合は本体と基本ライブラリと irb, tk 等が別パッケージに分離されてます。 > 要するにその労苦を払ってでもパッケージングポリシーを貫きたい、 > って事だと思うので、 > その範囲が拡大するだけなら対処してくれるのではないでしょうか。 あまり関係ないと思います。 パッケージ分割は様々なことを考えて パッケージメンテナ(と、もちろんパッケージユーザ)が 決めていくものですから。 # 「わざわざ」にもそれぞれのケースに応じて意味があるはずです。 > ただその場合、単純に考えると gem 化されている標準添付物は、 > 「パッケージ配布対象から除外される」になると思います。 > あるいはバージョニングを殺して site_ruby 下に再配置してパッケージング、 > でしょうか。成功したもののみ。 pre-installed-gemを含む配布物になった場合、 バイナリパッケージがそうなることもあるでしょうし、 単にどれかのパッケージの一部になることもあるでしょう。 もちろんパッケージメンテナの数だけ方針はあり得ると思います。 > あ、添付物同士で依存関係がある場合は・・・以下省略(ぉぃ 重要な部分がpre-installed-gemになった場合には バイナリパッケージの形をどうするにせよはずせなくなるでしょう。 # 単にパッケージ化をやめるという選択子もあり得るとはいえますが。 > 「耐性」とはパッケージマネージャが動き続けること、しか思い浮かびません。 > そして、その実例は乏しいと思います。 > こっちが重要と思っていますが。 > > 私が Fedora Core 6 で実験したところ、 > 0.9.2 の rpm をインストールし gem update で 0.9.4 にした後、 > rpm をアンインストールしてみましたが、 > 特に弱音は吐きませんでした。 > 再度 0.9.2 を rpm でインストールしたところ 0.9.2 として動きました。 > > 0.9.2 と 0.9.4 はそれなりにファイル構成が違いました。 > ディレクトリも増えたりしています。 > (サブコマンド毎にファイルが用意された?っぽかった。) そういう問題ではないと思います。 パッケージシステムはパッケージシステム自身の データベースのようなものをこわしでもしない限り パッケージの作りにしがって動作するものです。 そうではなくて、たとえば、多くのパッケージシステムでは 一括してパッケージを更新する機能が提供されています。 そういうとき、パッケージシステムにないところで 更新したファイルはパッケージシステムによっては 単に上書きされてしまいます。 gemによる更新を自分でやったのだから、 それはそのユーザの不注意だといえばもちろんそうでしょうが 「相性」という点ではこういうこともその一部だと思います。 # たとえそうなっても回避方法や修復方法があるのは分かっています。