[debian-users:12126] Re: historical info

["Ken N." <kenn@xxxxxxxxxxxxxxxxx>]

In <13990.910.200660.72159A@xxxxxxxxxxxxxxxxxx>
[debian-users:12114] Re: historical info, Jan.21 '99 01:25 JST
taru@xxxxxxxxxxxxx says:
=   At Wed, 20 Jan 1999 22:44:52 +0900,
=   Mitsuru Oka <oka@debian.or.jp> wrote:
=   > えっと、どこが事前条件なんでしょうか??
=   
=   「パッケージがインストールされる前に hoge と言う名前は退避
=   しなくてはいけない」という事前条件です。

「それでは柔軟すぎるよね」という話です。
パッケージが条件としてあげているのは、「私は``hoge''という名前
を占有しますよ。だから私をインストール(というか、より厳密には
unpack)するためには、『パス名前空間』というシステムリソース上
で``hoge''というリソースがフリーになっていなければいけませんよ」
ということですよね。それをうけて「あ、それじゃ今あるhogeは退避
しなくては」と判断するか、「おーけーおーけー、GOAHEAD!!」とす
るかはdpkg側でやった方が自然じゃない？ということを言っているわ
けです。


=   ルールを記述してそれを dpkg で処理する方式はいわゆる dpkg 主導
=   型の中央集中管理的なシステムです。この方式はクライアント側の
=   設計が楽になりますが、一方でサーバ側の負担が増えることになります。
=   しかも、その事前条件においてルールという記憶素子しかパッケージ情報
=   に組み込まないのなら、サーバはすべてのクライアントに対して、この
=   ルールはあなたのシステムで必要かという検証が必要になります。

「サーバ」「クライアント」が、この場合何のアナロジになっている
のかいまいち私は理解していないのですが、それはともかく、一般に
サーバ側で管理している情報のcoherencyやintegrityを維持するのは
サーバ側の仕事です。それをクライアント側にたよってしまうのは、
界面の設計を失敗していると言えます。

インストール/ アンインストール時のDebianシステムのcoherencyや
integrityを維持するのはまさしくdpkgの仕事であって、パッケージ
側の仕事ではないはずです。


=   この利点は hoge のプロセスがどこで動いていようが
=   構わなくすることもでき、エージェント化などと組み合わせれば非同期で、
=   より多彩な設定プロセスを行うことをできるようにすることも可能です。

「hogeのプロセス」の具体例として{pre,post}{inst,rm}を想定なさっ
ているのなら、これらは明白に位置依存だと思います。必然的に、
appletなどのような機種依存の無い実行イメージをダウンロードする
ことになりますが、そのときに、

=   ルールと制御を分けるという話もありますが、カプセル化の方がずっと自然だと
=   思います。

自然かどうかは何をカプセル化したかにもよるので、パッケージにど
のような自律性があるとどう便利なのかというのが見えないとなんと
も申し上げられませんが。


=   また、 preinst等 が shell script なのがあれだというのもありますが、
=   それは、たまたま shell script がユーザ可読なので、ずいぶん手抜きだという
=   風に感じてしまうというのがあると思います。

えと、私はそういう話はしていないし、岡さんもそういう論点ではお
話しされていないと思うんですが。


＃あと、オーバヘッドというのは何のことについておっしゃっていま
　すか？「実行速度」や「システムリソースの一時的消費」のことで
　はないとは思っていますが。

 -.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence