[debian-users:12010] Re: historical info (Re: Re: xf86-tt_updat...)

[Mitsuru Oka <oka@debian.or.jp>]

岡＠情報科学.高知大です。


"kenn"すなわち"Ken N."さんより:

kenn> oka@debian.or.jp says:
kenn> =   Ken> ＃履歴の概念そのものはOOでも扱えます(設計/ 実装が可能です)よ。
kenn> =   
kenn> =   クラスレベルの履歴ならともかくインスタンスレベルだと不可能じゃ
kenn> =   ないにしても、結構大変だと思いますが(^^;

kenn> インスタンスの履歴管理という事をインスタンス実行時の動的な状態
kenn> 管理という事に落し込むようにするというのではどうでしょう。動的
kenn> 状態管理については確かデザインパターンにもなっていたように思い
kenn> ます。その「管理下にある『状態』」を適切なタイミングでフリーズ
kenn> してスタックなりリストなりにしてしまう、と。

まあ、インスタンス生成のタイミング(コンストラクタ/dpkg -i)を
利用して「状態変化」を保存すればコンパクトな記憶領域に抑えら
れると思います。

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


kenn> なるほど、少しわかってきました。パッケージのインストールをオブ
kenn> ジェクトの具象化としてとらえるわけですね。apt/dpkgがコンストラ
kenn> クタになると。それは思い付きませんでした。

kenn> なかなか面白そうですね。何か具体的な分析/ 設計イメージはおあり
kenn> ですか？現在のdebian packageがもっている機能はどのように表現さ
kenn> れるか、そのモデルと現在のものとを比較した場合の利点は何か、と
kenn> くに柔軟性、拡張性とか、といったことですが。

kenn> たとえば、パッケージのセクション分けはどのように表現されるでしょ
kenn> う。この部分がきれいにクラス化されていれば、特に{pre,post}{inst,rm}
kenn> の再利用性や品質保持にメリットがあると思われますが。

あっ、これ無茶苦茶面白いですね。

  コンストラクタ → インストール
  デストラクタ   → アンインストール

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

昔、アプリケーションをクラス、アプリケーションの実行をインス
タンス生成と見ていろいろ考えてた事がありますが、パッケージに
対してもわりとうまく適用できそう...。


kenn> =   Ken> インストール済の*.deb についてもどこかに保持しておかなくてはな
kenn> =   Ken> らないですよね。でないと経時状態遷移を管理する意味が無いですか
kenn> =   Ken> ら。これも大変ですね。
kenn> =   
kenn> =   Ken N. さんがおっしゃってるのは先のオブジェクト指向で言う所
kenn> =   のインスタンスレベル(→Debian で言うとインストールされたパッ
kenn> =   ケージ)での保管じゃないですか? それはちょっと莫大というか、
kenn> =   大変です。

kenn> 私が個人的にDebian(と、RedHat)のpackaging systemをかぎまわって
kenn> いる理由の一つはインストール/ アンインストール時のユーザのシス
kenn> テムのIntegrity の維持について改善したいからです。特にunpack後
kenn> でpostinstがこけた時ですね、具体的には。(bo-updateにあったbash
kenn> とreadlineで痛い目を見た人が何人かいたはずです。) なので、どう
kenn> しても今インストールされているパッケージをどう守るか、という事
kenn> に目が行きがちです。

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

で、unpack 後にこけるのは、ほとんど現実的ではない話をすると、
ファイルシステムをレイヤー化すると防げます。新規にレイヤーを
作成して、以後はそちらのレイヤー上にファイルアクセスが反映さ
れるようにしてからインストール、成功した事を(何らかの方法で)
確認できたら元のレイヤーにある古いパッケージをアンインストー
ル、その後、二つのレイヤーを平坦化して普通の状態に戻します。

 # http://www.globe.to/~moka/memo.txt 参照

kenn> パッケージのremove/purgeをGCとしてとらえるなら、細かい事に気を
kenn> とられずに今インストール済のソフトウェアを保存することができそ
kenn> うです。不要になったら自動的にGCされるわけですから。これも興味
kenn> 深いアイディアですね。

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


kenn> ＃余談になりますが、上の理由のもう一つはユーザのシステムでの
kenn> 　SCM(Software Configuration Management)の機能を充実させたい、
kenn> 　というものです。なので、distributionの切り替わり時期で履歴
kenn> 　管理の管理範囲を決めるやりかたではだめということになります。

こっちはさらに大変ですね。locale や何やらと条件はたくさん...。

--
岡 充 (Mitsuru Oka)
高知大学理学部情報科学科4回生