[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