[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:12007] Re: historical info (Re: Re: xf86-tt_updat...)
In <19990116202524P.oka@debian.or.jp>
[debian-users:11967] historical info (Re: Re: xf86-tt_updat...), Jan.16 '99 20:25 JST
oka@debian.or.jp says:
= Ken> #履歴の概念そのものはOOでも扱えます(設計/ 実装が可能です)よ。
=
= クラスレベルの履歴ならともかくインスタンスレベルだと不可能じゃ
= ないにしても、結構大変だと思いますが(^^;
インスタンスの履歴管理という事をインスタンス実行時の動的な状態
管理という事に落し込むようにするというのではどうでしょう。動的
状態管理については確かデザインパターンにもなっていたように思い
ます。その「管理下にある『状態』」を適切なタイミングでフリーズ
してスタックなりリストなりにしてしまう、と。
で、本題ですが、
= Ken N. さんがおっしゃってるのは先のオブジェクト指向で言う所
= のインスタンスレベル(→Debian で言うとインストールされたパッ
= ケージ)での保管じゃないですか? それはちょっと莫大というか、
= 大変です。
=
= クラスレベル(→作成され公開されたパッケージごと)だとそこまで
= 複雑ではないと思います。
=
= クラスレベルだと、dpkg とは無関係にモデルを用意できます。持
= たせるなら apt レベル。ディストリビューションのアップデート
= の際にこの情報を元に推論してパッケージを取捨します。xtt への
= 移行も思いの他スムーズにいきます。
なるほど、少しわかってきました。パッケージのインストールをオブ
ジェクトの具象化としてとらえるわけですね。apt/dpkgがコンストラ
クタになると。それは思い付きませんでした。
なかなか面白そうですね。何か具体的な分析/ 設計イメージはおあり
ですか?現在のdebian packageがもっている機能はどのように表現さ
れるか、そのモデルと現在のものとを比較した場合の利点は何か、と
くに柔軟性、拡張性とか、といったことですが。
たとえば、パッケージのセクション分けはどのように表現されるでしょ
う。この部分がきれいにクラス化されていれば、特に{pre,post}{inst,rm}
の再利用性や品質保持にメリットがあると思われますが。
= あと、ガーベッジコレクションに相当する、パッケージの自動除去
= というのもちらっと考えています。一番単純なのは、何月何日付け
= でパッケージを削除とか。特定のコンディションを与えておいて、
= それを満たした時に(cronとかで定期的にチェック)削除とか。
なるほど。
ちょっと引用前後しますが、
= Ken> インストール済の*.deb についてもどこかに保持しておかなくてはな
= Ken> らないですよね。でないと経時状態遷移を管理する意味が無いですか
= Ken> ら。これも大変ですね。
=
= Ken N. さんがおっしゃってるのは先のオブジェクト指向で言う所
= のインスタンスレベル(→Debian で言うとインストールされたパッ
= ケージ)での保管じゃないですか? それはちょっと莫大というか、
= 大変です。
私が個人的にDebian(と、RedHat)のpackaging systemをかぎまわって
いる理由の一つはインストール/ アンインストール時のユーザのシス
テムのIntegrity の維持について改善したいからです。特にunpack後
でpostinstがこけた時ですね、具体的には。(bo-updateにあったbash
とreadlineで痛い目を見た人が何人かいたはずです。) なので、どう
しても今インストールされているパッケージをどう守るか、という事
に目が行きがちです。
パッケージのremove/purgeをGCとしてとらえるなら、細かい事に気を
とられずに今インストール済のソフトウェアを保存することができそ
うです。不要になったら自動的にGCされるわけですから。これも興味
深いアイディアですね。
#余談になりますが、上の理由のもう一つはユーザのシステムでの
SCM(Software Configuration Management)の機能を充実させたい、
というものです。なので、distributionの切り替わり時期で履歴
管理の管理範囲を決めるやりかたではだめということになります。
-.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「人は船ではない。人は会社ではない」-- Gerry Spence