[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[dennou-ruby:002766] 電脳製品 のパッケージング
- To: davis-ml@xxxxxxxxxxxxxx, dennou-ruby@xxxxxxxxxxx
- Subject: [dennou-ruby:002766] 電脳製品 のパッケージング
- From: KOSHIRO Tsuyoshi <koshiro@xxxxxxxxxxxxxx>
- Date: Wed, 14 Mar 2007 11:59:19 +0900
神代です.
先日の電脳davis/rubyワークショップでは, パッケージングの話を私がする予
定でしたが, 時間切れになってしまったので, ここで補足します.
----------------------------------------------------------------------
1. プラットホーム毎の(バイナリ)パッケージ
現状では, 以下のようにプラットホーム毎のパッケージが用意されています.
apt等も使えるようにしてあるのがミソで, インストールが楽にできます.
作成者の皆様, いつもありがとうございます.
・deb <apt> [i386] ... 小高さんはじめ北大の方々
・RPM -- Vine <apt> [i386], Fedora <yum> [i386, x86_64] ... 神代, 西澤さん
・FreeBSD ports ... 村上さん
・MacOSX Fink [PowerPC, Intel] ... 岩前さん
・Windows (MSWin32) 全部入りパッケージ ... 乙部さん
・Cygwin <setup.exe> ... 神代
これらは, 今後も継続していけたらと思います. (お願いします)
64bit PC もだんだん普及してきたので, Linux ではそれに対応したパッケー
ジも用意できるといいですね(今はFedoraだけ).
RPMは CentOS あたりも用意できるといいかなーと妄想はしています.
2. プラットホームに依存しないインストーラ
これら以外の環境のために, 一括インストーラ numru-install.rb なるものを
用意していました.
これはRubyスクリプトで, Rubyさえあれば動き, DCLやnetCDFも含めて電脳製
品を一括インストールでき, 依存関係も考えてくれるように作ったものです.
が, 自前でインストーラの枠組みを作るのはなかなか難しく, 設計があまりよ
くなかったのもあって(これは私が悪いんですが), 現状ではほとんどメンテで
きていません.
そこで, こいつはやめて, RubyGems のパッケージを作るのがいいんじゃない
かと最近考えています.
今回, Ruby on Rails をインストールするときにこれを使った方も多いと思い
ますが, Rails 人気のおかげで, Rubyライブラリパッケージ管理システムのデ
ファクトスタンダードになりつつあります.
# 今後, Ruby本体に取り込む予定もあるようです([ruby-dev:30560])
具体的な作りかたはだいたいリサーチしたのですが, 実際に作成するのはまだ
これからです. 問題点があればまた報告したいと思います.
NArrayなどの外部製品のgemも, ないようなので作るつもりです.
これができれば, Gfdnaviのインストールが
・DCL, netCDFあたりは, 手動でビルド, インストールする
・Rubyはもちろん必要
・gem をインストール
・電脳製品を gem install
・Rails を gem install
・Gfdnavi を手動で取得, 展開, rails gfdnavi
というような手順でできるようになります.
----------------------------------------------------------------------
以下は, 堀之内さんが流してくださったメモに対する反応です.
パッケージング関連のところだけ.
At Mon, 12 Mar 2007 13:06:40 +0900,
Takeshi Horinouchi wrote:
>
> * 配布版パッケージング再構成
> * 現在は DLして展開したものをそのまま編集して使わせてるが、
> DL and (展開 or インストール)後、運用用の場所に改めて
> 展開させる(各userのディレクトリーとか /var とか)。
> * パッケージには運用用の場所に展開するための setup コマンド
> を含めるか、それ自体を setup.exe にする。
> * gfdnavi の配布版パッケージングと、各自の運用用コピーの分離
> * gfdnaviがバージョンアップしてもやり直ししないで済むように
> * 配布版からはじめても cvs 版も使えるのが良い。
これは, Rails みたいな感じをイメージしたらよいでしょうか?
つまり,
・インストール時には, Gfdnavi はコマンド+ライブラリ(コピー元資源)のか
たちになっていて, この時点では運用用の資源は展開されていない.
・自分が運用したい場所で gfdnavi_setup みたいなコマンドを実行すると,
そこに資源がコピーされ, rails コマンドも実行される
というような.
Gfdnavi をパッケージングするなら, そのように変えないといけないだろうな
と私も考えていました.
> * ユーザディレクトリ や /var にインストール後に、make setup
> に続けられるようにするとよいだろう(後で setup するオプション
> も残す。)
すみません, これはちょっとよくわからなかったです.