[debian-users:12046] Re: historical info

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

In <19990117213114S.oka@debian.or.jp>
[debian-users:12010] Re: historical info (Re:  Re:xf86-tt_updat...), Jan.17 '99 21:31 JST
oka@debian.or.jp says:
=   まあ、インスタンス生成のタイミング(コンストラクタ/dpkg -i)を
=   利用して「状態変化」を保存すればコンパクトな記憶領域に抑えら
=   れると思います。

そう、「状態変化」または「状態の差分」の保存ですね、やるとしたら。

=   # でも、なんでスタックなんです?? (^^;
=   # 履歴だからストリームとか、キューになりそうなんですが...。

これは、「主としてアクセスするのは『現在』の状態にたいしてであ
ろう」という予測からです。最も頻繁にアクセスする物にはアクセス
しやすいところにいて欲しい。streamやqueue でも別に現在の状態(
最後に投入された状態)にアクセスできないわけではないけど、これ
らのデータ構造は基本的には読みだしのための注視点は先頭(最も昔)
になりますよね。

あと、過去の状態を復元したい時にはpop 操作の方が合理的です。復
元とは任意の過去状態を取り出すわけではないのですから、dequeue
などとは操作の本質が異なります。


=   インストール中の状態変化をコントロールできるメソッドがあれば
=   楽しいかも...。dpkg -r はある意味、オブジェクト凍結みたいな
=   感じですかねぇ、状態は残したまま外してしまう所が。

コンフィグレーションだけがそのパッケージの状態をあらわすもので
あればそのとらえかたでもいいと思うのですが、それだけではないと
思うんですよ。たとえば、「このコンフィグレーションファイルが正
しくセットアップされるまでは、このdaemonのサービスは開始したく
ない」とかいう場合、コンフィグレーションの有無そのものはもう、
「状態」というよりは「状態間を遷移するための条件」になりますよ
ね。この例の場合だと、「インストール済状態」->「サービス提供可
能状態」といったかんじですね。


=   正常な状態の破綻は、オブジェクト指向における、クラス不変条件
=   の破綻に似てますし、インストールやアンインストールの失敗/成
=   功は事前条件・事後条件と対応付けられそうです。
=   # Eiffel から入った口なので...。

preinst はまさしくインストール(というか、正しくはunpack)のため
のpreconditionを満足させるためのものですが、Debianの場合には条
件を定義するものではなくて単にshell scriptです(ではないものも
あるが)よね。柔軟なのだけれど、ここはむしろ事前条件だけをきっち
り記述すればdpkg側でその条件を満たす処理を実行する、というよう
にしたいですよね。

Eiffelで書くのも悪くないと思います。言語コンセプトとしてEiffel
がもっている仕様記述能力を考えれば、むしろ適切な解かもしれない。


=   で、unpack 後にこけるのは、ほとんど現実的ではない話をすると、
=   ファイルシステムをレイヤー化すると防げます。

実は同じ事を昨年の7,8 月頃に考えていて、ちょろっとここに書いた
ことがあります。overlay filesystemでunpackの事象地平をなくせな
いだろうかとかなんとか。


=   # いろいろあるんですが、考えるだけで実装能力(実行能力)が無い
=   # のでいつも絵に描いた餅です ;-)

私もいずれは少しまとまった時間を作って何かインプリメントしたい
と思っているんですけどね。メモ書き(電子化されてない^^;)がふえ
るばかりで。

＃岡さんには期待してるんですよ。パワフルだし(今は少しお忙しい
　のかな)、発想力は私などよりはるかに柔軟ですし。

＃＃うーむ、トシを感じる... (^^;


今日はこのくらいで。

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