[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-users:11965] Re: xf86-tt_updat e-0.1.3.shについて
In <19990116091042A.oka@debian.or.jp>
[debian-users:11955] Re: xf86-tt_updat e-0.1.3.shについて, Jan.16 '99 09:10 JST
oka@debian.or.jp says:
= Debian のパッケージシステムに足りない部分が露骨に見え隠れし
= てますね...。依存関係によるシステムって、オブジェクト指向モ
= デルに非常に似てますけど、どちらも静的なもので時系列の概念を
= うまく表現できないのが弱いと思います。
例えば、ある時点での依存関係なりオブジェクト群のconformationな
りのsnapshotを格納するオブジェクトを用意して、そのオブジェクト
自身はスタックの機能を持つ(別に継承でも委譲でもいい)ようにすれ
ば時系列を空間配列に展開できそうですね。ただ、それが必ずしもオ
ブジェクト指向的かと言うとなんともいえないわけで... って、それ
はDebianとは関係ないか (^^;
#履歴の概念そのものはOOでも扱えます(設計/ 実装が可能です)よ。
= Debian の場合、全パッケージの history みたいなのを別ファイル
= で用意して、時系列遷移関係を表現するといいんじゃないかと思い
= ます。
ふむ。
/var/lib/dpkg/をcvs で管理するとかでしょうか、やるとしたら。
ただ、いかんせんパッケージ数がアレなんで、膨大どころかあっさり
破綻しそうな気がします、よほど入念に設計しない限り。
インストール済の*.deb についてもどこかに保持しておかなくてはな
らないですよね。でないと経時状態遷移を管理する意味が無いですか
ら。これも大変ですね。
このあたりのことは私もあれこれ考えてみたことはあります。尤も、
私の場合は「インストール破綻時に旧態を安全に復元可能な事」とい
う視点で考えていたのですが。
Debianの場合、依存/ 競合関係の管理単位が「パッケージ」であるこ
と、全パッケージをリストする``Available list''との関係も考える
必要があること、かつ、パッケージ数が既に膨大であることから、現
実的な改善策を私はみつける事ができませんでした。
#available listの概念を捨てて、依存/ 競合関係をファイルの粒度
で管理する、というのまで考えたんですが、そこまでやったらもう
dpkgじゃない...
-.- . -. -.
Ken Nakagaki <kenn@xxxxxxxxxxxxxxxxx>
「会社は主にそれ自身の慣性によって前進している」-- Gerry Spence