[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:12114] Re: historical info
樽石です。
At Wed, 20 Jan 1999 22:44:52 +0900,
Mitsuru Oka <oka@debian.or.jp> wrote:
> 樽石> 事前条件をきっちり記述しているのが preinst ではないかという
> 樽石> 考えはおかしいでしょうか？
> 樽石> 例えば、diversion をしたい場合なんかは
>
> 樽石> dpkg-divert --package hoge --add --rename \
> 樽石> --divert hoge.no hoge
>
> 樽石> って事前条件きっちり指定してますよね。
>
> えっと、どこが事前条件なんでしょうか??
「パッケージがインストールされる前に hoge と言う名前は退避
しなくてはいけない」という事前条件です。
#dpkg-divert を前置するのが退避事前条件を指定する方法
> # そもそも「条件の充足チェック」に副作用があってはならないよ
> # うな気がする...。
それをプログラムのバグというと思います。
#まあ、バグの起こりにくい仕様の方が良いというのもありますが…
> 樽石> あまり、実行時にモデル化したものばかりにするとオーバヘッドが
> 樽石> 大きくなるとなると思います。それよりは debhelper がもっと高機能
> 樽石> になって、 build 時に処理できるようにしたほうが良いと思います。
>
> 何で実装するかにもよりますが、せいぜいインタプリタと同じ速度
> で検証できると思います(むしろ bash の方が遅いかも)。確かに
> debhelper はそれなりにモデル化されているなとは思いますが、ルー
> ルの記述と制御の記述とは全然意味が違います。
ルールを記述してそれを dpkg で処理する方式はいわゆる dpkg 主導
型の中央集中管理的なシステムです。この方式はクライアント側の
設計が楽になりますが、一方でサーバ側の負担が増えることになります。
しかも、その事前条件においてルールという記憶素子しかパッケージ情報
に組み込まないのなら、サーバはすべてのクライアントに対して、この
ルールはあなたのシステムで必要かという検証が必要になります。
たしかに、このようなパラダイムで動くシステムでも悪くはないですし、
実際そのようなシステムも多いかと思います(?)。しかし、もっとエレガント
に事象処理を考えた場合、なぜクライアントに必要な部分をサーバが
検証しないといけないのかという疑問にぶちあたります。クライアントが
必要な作業ならクライアントが要求すべきであると思います。つまり、サーバ
とクライアントがお互い意志を持ったプロセスのようにふるまい、お互いが
通信しあいながら、処理を進めたほうが自然ではないかということです。
実はこの方式は「オブジェクト指向パラダイム」に近いものがあります。
つまり、dpkg と パッケージ(の設定プログラム)は、それぞれが
インスタンスとして、自分の決められた仕事をこなしていって、
結果を相手に伝えるというスタンスです。 例えば、先の「退避」を
要求する事前条件を必要とするパッケージのインストールがあったとします。
dpkg のインスタンスを dpkg、 このパッケージを Hoge、設定プログラムの
インスタンスを hoge とします。
ユーザ： Hoge パッケージのインストールを開始する。
dpkg は Hoge のインストールを行う準備を開始する。
Hoge の 設定プログラムインスタンス hoge を作成する。
dpkg: 「おーい、 hoge。 インストールするよ。」
hoge: 「えーと、じゃあ、 foo ってファイルを foo.foo にしてください。」
dpkg: 「了解。 じゃあ、圧縮ファイルを展開するよ…」
…
dpkg: 「あ、依存関係があるねぇ。君はインストールできないよ。」
hoge: 「え、そうですか。じゃあ、foo.foo は foo に戻してください。」
dpkg、 depenency problem をユーザに発行。
ユーザ： インストールエラーを認識する。
という、感じになります(注 この処理の詳細は Packaging Manual 6.3 を参照)。
ルール化による dpkg の一元管理よりはずっと自然なプロセスになると思います。
また、この処理は OSI 参照モデル でいうならばアプリケーション層の
部分でしかないので、下層のネットワーク層やデータリンク層などには
依存しません。この利点は hoge のプロセスがどこで動いていようが
構わなくすることもでき、エージェント化などと組み合わせれば非同期で、
より多彩な設定プロセスを行うことをできるようにすることも可能です。
ルールと制御を分けるという話もありますが、カプセル化の方がずっと自然だと
思います。また、 preinst等 が shell script なのがあれだというのもありますが、
それは、たまたま shell script がユーザ可読なので、ずいぶん手抜きだという
風に感じてしまうというのがあると思います。preinst 等の、設定プログラム
は、システムで実行可能な形式ならばなんでもいいわけで、これは ELF のもの
なら、 shell script よりはしっかりしたシステムのように見れるでしょう。
「みれるでしょう」というのがポイントで、ようは設定プログラムは単に実行
ファイルだというだけのことです。
このへんの設定インスタンス側がどうあるべきかというのは、また議論の
あるところだと思いますが、現状 Debian/GNU Linux が、カーネルに Linux
を採用していたことから、プロセスの実行が一番、自然だったからそういう
実装になったのだと思います。Debian/GNU Java/OS だったら、設定プログラムは
Class だったかもしれません。
----
Masato Taruishi <taruis-m@xxxxxxxxxxxxx> | University of Electro Comunications
<taru@debian.or.jp> | Department of Computer Science
<taru@xxxxxxxxxxxxx> | Junior
http://www.sunicom.co.jp/~taruisma/ | Chofu city Tokyo, JAPAN
Key fingerprint = 49 46 74 E1 8D D1 EB 56 8D CA 2A 20 14 9E A9 25