[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ruby packages



portsたくさんパクらせていただいております > knuさん

で、Rubyに関しては、
RubyにもperlのCPANモジュールのようなものがあるといいなぁ、とか思ってます。
	# perl -MCPAN -e shell
	cpan> install Jcode
拡張モジュールならextconf.rbである程度吸収できちゃってますが。
Rubyで共通のインストールフレームワークがあれば、
ports/packages、それ以外のパッケージシステムでも楽になるだろうなぁ、とか。


knu@iDaemons.org wrote:

 >  その後考えたのですが、結局、同期というのは無駄が多いように
 > 思えてきました。YAGNI ですな。OpenPackages が具現化したら、結局
 > 変換する手間が掛かるのは同じなので、そのときに合わせればいいこと
 > ですよね。

portsをimportしてNetBSD用に変換したpackageはいくらでも見ますが、
二回目のimportをしたpackageを見たことがないような気がしたりして(^^;
ソフトウェアがバージョンアップした場合、portsは見ないで変更してたり...


 >  つまり、パッケージシステムがその中で閉じて管理できるようにする
 > 代償として、ユーザが手で導入したライブラリやツールの類の利用・
 > 共存という道を(ほぼ)切り捨てる英断の一環であるということです。

CONFLICTSなんかもそれですかね。


 >  私自身は、 Debian や RPM の高度なパッケージ管理手法をある程度
 > 知ってからは、 FreeBSD ports をパッケージシステムとして改良して
 > いくことよりも、ビルド支援システムとして磨いて行く方があるべき
 > 姿に近いような気がして、そちらに重心を置いています。

今日かっぱらったfox ports見てもわかります。
port2pkgしたときにconfigureのargument制御の部分ばっさり落しました。
私的には

 >  具体的に言うと、閉じたパッケージ管理システムでは実現が難しい、
 > ビルド時のオプション指定やカスタマイズ、ユーザが自分で導入した
 > バージョンのライブラリやツールの利用といったことです。

は、localでpkgsrcを書き換えていって欲しいと思っています。
書き換えた結果に共通性、公共性?があるならば、
send-prなりでpkgsrcに反映してもらえばいいかなと。
anonymous cvsあるからlocalで書き換えたまま
最新とmergeなんてことも簡単ですから。


あとportsとpkgsrcの柔軟性の差は、メンテナの人数差にもよるのかなとも思ったり。
pkgsrcの10倍くらいportsメンテナがいそうな気がしてなりません。

sakamoto