[debian-users:12132] Re: historical info

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

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


大事な事を書き忘れてましたが、[debian-users:12131] やそれ以
前で書いている「事前条件」の話と「{pre,post}{inst,rm}のモデ
ル化」の話は一応切り離して考えて下さい。

どこから混ざったのか、書いてる僕も混同して書いてたかもしれな
いです...。


# だんだん指向^H^H思考能力が低下してきてるので話についていけ
  るかどうか...。

"kenn"すなわち"Ken N."さんより:
kenn> 本題の方の続きです。

kenn> パッケージ間の依存関係は``has a'' で素直に表現してしまえばいい
kenn> として、もともとの話題だった時間経過に伴うパッケージ構成の変遷
kenn> はどう表現できるでしょうか。私はまだちょっとイメージがわかない。

# んでもって、virtual package が Objective-C の protocol、
  Java で言う interface というわけですね。継承は要らないみたい。

パッケージ構成の遷移は、うまく記述できないですね。これは関係
や形じゃなくてクラスにおける状態の変化(強いて言えば時間軸の
作用)だから、オブジェクト指向に馴染まないような気がします。
単一のクラスの差し替えならともかく、多対多の対応付けですから。


kenn> とりあえず、構成の変更はリリースのタイミングでのものに限定して
考えてみる(hamm->slinkのような)として、たとえばhammのxbaseとslink
kenn> の「元xbaseだった」パッケージ群との間の関係をどのように表現しま
kenn> すか？

一言で言うと、一意の答はありません。パッケージメンテナの技量
というしかない...。これじゃいけないですね...。

kenn> あと、競合関係の表現が意外とむづかしいと思うんですよ。

結構矛盾が生じるかもしれませんね。


kenn> そうですねー、状態を単にpushするのでなく状態差分をということな
kenn> らundo/redo で考えた方がいいんでしょうね。ただ、底に溜った物が
kenn> ゴミになるかどうかはどんな使われ方をするかにもよります。

それはもちろん。

kenn> ところで、インストール済パッケージの変遷についても履歴管理する
kenn> として、これとGCのアナロジを組み合わせるとすると、どうなるんで
kenn> しょうね。undo /redoとして管理されているパッケージ状態からの有
kenn> 向グラフになるようにすればいいのかな。古くなってもういらなくなっ
kenn> た『状態』をぽいっと捨てるとそこだけに連なっていたパッケージが
kenn> ごそっと捨てられる... そんなかんじでしょうか。

本気で GC 化すると、パッケージに新たな属性を付けるか、インス
トール状態に新たな属性を付ける必要があります。

話を単純化すると、ライブラリは依存されているからインストール
されているだけで、単体では必要ない、と考えます。-dev やアプ
リケーションはそうではないです。こう考えると、前者のようにパッ
ケージに属性をつければ対処できます。

しかし、ライブラリであっても本人の希望により入れておきたいな
どという状況(どうせ後でまた必要になるんだから、いちいちアン
インストールされては困る、など)まで細かく考えると、後者のイ
ンストール状態において新たな属性が必要です(hold みたいな感覚
で)。

# もうちょっと気の利いたアイディアが出てもよさそうなんですが、
# もう思考能力が無くなったのでこれにて...。
--
岡 充 (Mitsuru Oka)
高知大学理学部情報科学科4回生