アカウント名:
パスワード:
1=[major] 6=[minor] 8=[teeny]
とされています。この場合「メジャーバージョン」は明らかに「1」でしょう。「スクリプトの互換性が高くないから1.6→1.8はメジャーバージョンアップ」というのは、俺解釈以外の何物でもないと思いますが。
かつてMLでの議論の中で、まつもとさんは仕様は線型に変化するわけではない [nagaokaut.ac.jp]と発言しています。つまり、同じ1.6系列でも非互換が生じる場合がありうる、ということでしょう。
私自身は ruby 使いではないので試したことないのですが、このへん [gentoo.gr.jp] が詳しいです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
もともと (スコア:1)
良さを説明したURLとか希望。
あと、java系のプログラムを使うことが多いけど、
Mavenみたいなライブラリ管理と統合してくれると
うれしいんだけどなあ。
Re:もともと (スコア:0)
Re:もともと (スコア:1)
そして、バイナリ配布もできること、と。
Re:もともと (スコア:0)
Re:もともと (スコア:2, 参考になる)
Portsによって決められています。Portageの場合、ユーザが
複数のバージョンから、使用したいものを選択できます。
Re:もともと (スコア:1)
ここで言うバージョンとはどのような物ですか?
例えば、Rubyだと、1.6系と1.8系でメジャーバージョンが違い、
メジャーバージョンの中で例えば、1.6.4や1.6.8などとマイナーバージョンがあります。
portsの場合、1.6系である、lang/ruby16と
1.8系である、lang/ruby18があり、そこから選びます。
ここでのバージョンとはメジャーバージョンですか、
マイナーバージョンですか?
マイナーバージョンを選択するという事はあまり考えられない気がするのですが?
#ごくたまに古いバージョンが必要になるかもしれないが、
逆に、メジャーバージョンの場合、共存などを考えると、
違うパッケージにした方が良い気もするのですが。
#もしくは、同じバッケージの違うバージョンをインストールできるようになっている?
教えて偉い人
Re:もともと (スコア:0)
>マイナーバージョンですか?
基本的には両方です。
たとえば「Xとかは安定してる(Gentooで推奨している)Versionを
使いたいが、KDEやGentooなどは最新版を追っかけたい」という
Re:もともと (スコア:1)
cvsで行いますので、このディレクトリだけ(例えばkde/*だけ)は
Currentにするといった芸当ができます。
#絶対に推奨はされないでしょうけど。
Re:もともと (スコア:0)
ports は最新を追いかけるのには便利ですが、そうじゃない使い方をしようと思うと途端に面倒、という印象があります。
# ports wizard はどうやって解決しているのだろう
Re:もともと (スコア:0)
そうじゃない使い方をしたい時には、素直にソースからビルドします。
へえーっ、そうだったんだー (スコア:0)
> い、 メジャーバージョンの中で例えば、1.6.4や1.6.8などと
> マイナーバージョンがあります。
.6 とか .8 はマイナーバージョンだと思っていました。
また、1.6.4 や 1.6.8 などの .4 や .8 はバグフィックス用の、いわゆるパ
Re:へえーっ、そうだったんだー (スコア:1)
動作をするものがマイナーバージョンアップと言う事が多いと思います。
Rubyの場合、1.8で動いて、1.6で全く動かないスクリプトがかなり多いと思いますので、
1.6や1.8はメジャーバージョンだと思います。
ruby-lang.orgを簡単に見てみましたが、開発者のみなさんは、
どれをメジャーだとか決めていないようですし、
多くの人に通じる上のような言い方が良いのではないでしょうか?
#必要なら、どういう意味で使うか示した上で。
単純に最上位桁がメジャーバージョンを示すとすると、
Java2はメジャーバージョンではなくなってしまいます。
#Java5はOK?
Re:へえーっ、そうだったんだー (スコア:2, 参考になる)
1=[major]
6=[minor]
8=[teeny]
とされています。この場合「メジャーバージョン」は明らかに「1」でしょう。「スクリプトの互換性が高くないから1.6→1.8はメジャーバージョンアップ」というのは、俺解釈以外の何物でもないと思いますが。
かつてMLでの議論の中で、まつもとさんは仕様は線型に変化するわけではない [nagaokaut.ac.jp]と発言しています。つまり、同じ1.6系列でも非互換が生じる場合がありうる、ということでしょう。
Re:へえーっ、そうだったんだー (スコア:1)
ありがとうございます。
それを元に先の私のコメントを書き直すと、
「ここで言うバージョンとはどのような物ですか?
例えば、Rubyだと、1.6系と1.8系で互換性が無いバージョンの差があり、
それぞれのバージョンで例えば、1.6.4や1.6.8などとある程度互換性があるものがあります。
portsの場合、1.6系である、lang/ruby16と
1.8系である、lang/ruby18があり、そこから選びます。 」
ですね。
話を戻しますが、
1.6と1.8の間では、結構差があるので、
1.6では動くが、1.8では動かないというソフトウエアがあるように感じます。
そのために、Portsでは、ruby16とruby18を区別しているのでしょう。
#もちろん、必要に応じて選べるため。というのもありますが、
パッケージシステムのもう一つ重要な機能に、
依存関係の解決というものがあります。
例えば、PortsでRubyで動くソフトウエアをインストールする時は、
Rubyがインストールされているかをチェックし、
必要に応じてRubyをインストールします。
この時、Ruby1.6でしか動作しないソフトウエアをインストールするには、
Ruby1.6を用意する必要がありますが、この管理はどうやるのが一番良いのでしょうか?
一つの解決策として、FreeBSDのPortsのように、
Ruby1.6にruby16という名前をつけて、Ruby1.8とは区別するという方法があります。
また、そのパッケージが作られた時の依存しているパッケージの
バージョンを記録しておいて、それ以外のバージョンだと警告を出す
などといった方法も考えられます。
しかし、どれも決定打という風には感じられません、
人間が行う作業が多いからです。
なぜ、人間が行う必要があるかと言うと、バージョンが
ツリー状に分かれていて、それ以降に分岐するという事が予測できないからです。
何か良い方法は無いでしょうか?
Re:へえーっ、そうだったんだー (スコア:0)
オフトピックですが参考まで(CVSWeb):
pkgsrc/mk/buildlink3/PKGVIEWS_UG - view - 1.1 [netbsd.org]
Re:へえーっ、そうだったんだー (スコア:0)
僕は,実際にどうやるのか・使い物になるのかなど,詳しくは知りません.
portage: Ruby の SLOT 対応 (スコア:1)
私自身は ruby 使いではないので試したことないのですが、このへん [gentoo.gr.jp] が詳しいです。
むらちより/あい/をこめて。
Re:もともと (スコア:1, 参考になる)
1. Fink - Perl
2. ports - make/shell
ports を利用しているシステムに EasyPackage があります。
3. Portage - Python + Bash
# 間違ってたら指摘よろ