[debian-users:12162] Re: historical info

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

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


"樽石"すなわちMasato Taruishiさんより:

樽石>      <システム>.dpkg-divert, <システム>.update-alternatives 等へのインタフェース
樽石>                                                      | 
樽石>  +--------+ <-----------------------------------+    |
樽石>  |        |         +-------------+             |    |
樽石>  |システム|   (1)   |インストール |             |<---+
樽石>  |  情報  | <------ |(必要時に (2)|             |
樽石>  |        |         |呼ぶ)--> ◯ <------+       |
樽石>  +--------+         +-------------+|    |       |  a class implementing Package
樽石> |                          +=======+ +--+-------+--------+    |
樽石> +===============+==========+         |{pre,post}{inst,rm}|<---+
樽石>                 |                    +-------------------+
樽石>              現行のdpkg
 
樽石> (1) dependency check、 展開要求、 エラー例外等の取得
樽石> (2) 他態性部インスタンス

樽石> つまり、 (2) は手続きでなくて、オブジェクトではないか
樽石> と思っているのです。

# 図は半分ぐらいしか理解できてませんが(^^;

もちろん、そう見立てるでしょう。{pre,post}{inst,rm} は XX パッ
ケージというインスタンスの  メソッドで、「パッケージ抽象クラ
ス」から継承ないしは「パッケージインタフェース」の実装という
ことですよね。

僕が言いたいのは、その {pre,post}{inst,rm} の粒度が粗すぎて
問題が多すぎる、もっとモデル化(=データフォーマット化)して簡
潔に扱えないかということです。


> 樽石さんが書いていたのにちょっと反論して書いただけで、カプセ
> ル化を意識しているわけではないです。それよりむしろ、いかにデー
> タフォーマットたり得るか、を考えています。例えて言えば、
> PostScript と PDF、DynamicHTML と XML(as Web Data) って所
> でしょうか、対極的でしょう? # 言葉少なすぎるかな...。

樽石> つまり、パッケージはデータ部のみを持つものにしようってことですね。

そういうことになります。

樽石> 僕は、パッケージはデータ部と他へのインタフェース(そしてまた、dpkg
樽石> 側もデータ部と他へのインタフェース)を持っているべきだと思って
樽石> いるのです。つまり、現状の {pre,post}{inst,rm} は、dpkg から パッケ
樽石> ージへのインタフェース、dpkg-divert 等は、dpkg へのインタフェースです。

現行の divert の問題は、多層化されていない点です。ちょうど
Z80 の裏レジスタみたいなもので、一時しのぎにしか見えません。
同名ファイルのスタック化(ML や、多くの言語での同名変数のスコー
プ規則みたいなものです)、ないしはちょっと前に述べたレイヤー
ドファイルシステムみたいなのが欲しい(でも、...ファイルシステ
ムの速度低下が致命的な問題でしょうね...)。

dpkg と外部とのモデル化されたインタフェースについては先に述
べました。menu や emacsen のようなのもそうだし、バグオブジェ
クトを登録、消化削除する操作もこれにあたります。

# あ、でも dpkg でやるか、apt レベルでやるかは、一考の余地が
# ありますね、やっぱり。
--
岡 充 (Mitsuru Oka)
高知大学理学部情報科学科4回生