[debian-users:12135] Re: historical info

[Masato Taruishi <taru@xxxxxxxxxxxxx>]

樽石@電通大です。

At Thu, 21 Jan 1999 16:28:29 +0900,
Ken N. <kenn@xxxxxxxxxxxxxxxxx> wrote:

> =   > えっと、どこが事前条件なんでしょうか??
> =   
> =   「パッケージがインストールされる前に hoge と言う名前は退避
> =   しなくてはいけない」という事前条件です。
> 
> 「それでは柔軟すぎるよね」という話です。
> パッケージが条件としてあげているのは、「私は``hoge''という名前
> を占有しますよ。だから私をインストール(というか、より厳密には
> unpack)するためには、『パス名前空間』というシステムリソース上
> で``hoge''というリソースがフリーになっていなければいけませんよ」

つまり、それを dpkg 側でやる作業をそくすメッセージが dpkg-divert だと
思うのですが… diversion するには dpkg-divert を呼び出すという制限を
課しているわけです。そうすれば

> ということですよね。それをうけて「あ、それじゃ今あるhogeは退避
> しなくては」と判断するか、「おーけーおーけー、GOAHEAD!!」とす
> るかはdpkg側でやった方が自然じゃない？ということを言っているわ
> けです。

dpkg-divert することが dpkg が判断や処理をやっているということに
なると思います。

> =   ルールを記述してそれを dpkg で処理する方式はいわゆる dpkg 主導
> =   型の中央集中管理的なシステムです。この方式はクライアント側の
> =   設計が楽になりますが、一方でサーバ側の負担が増えることになります。
> =   しかも、その事前条件においてルールという記憶素子しかパッケージ情報
> =   に組み込まないのなら、サーバはすべてのクライアントに対して、この
> =   ルールはあなたのシステムで必要かという検証が必要になります。
> 
> 「サーバ」「クライアント」が、この場合何のアナロジになっている
> のかいまいち私は理解していないのですが、それはともかく、一般に
> サーバ側で管理している情報のcoherencyやintegrityを維持するのは
> サーバ側の仕事です。それをクライアント側にたよってしまうのは、
> 界面の設計を失敗していると言えます。

クライアント側にたよる設計とはこの場合、/var/lib/dpkg/diversion 
を sed などで勝手にいじることであって、 dpkg パッケージの一部であ
る dpkg-divert というインタフェースを通して実行する方式はサーバ
側の管理している情報をサーバがきちんと仕事をしていると言えないでしょうか？
#これがちがうならオブジェクト指向的設計(特にカプセル化)
#は全て設計の失敗ということになると思います。

それで

> インストール/ アンインストール時のDebianシステムのcoherencyや
> integrityを維持するのはまさしくdpkgの仕事であって、パッケージ
> 側の仕事ではないはずです。

で、Debian システムの coherency や integrity の維持のために
「Depends, Recommends, Conflicts, Replace, Suggests 」等以外
にも diversion 等のルールを加えるかという当初の話についてい
うならば、僕は Depends 等の情報もルールとして持つべきではない
と思います。 ルールを dpkg に渡して調べさせるのでなくパッケージ
が自分で調べるべきだと思います(その作業構築のためのためのルール
を debian ソースににいれることは問題ないと思います。それが 
debhelper が高機能になるということです)。つまり、あるパッケージ
に特有の depends や recommends といった情報はパッケージが調べ
ることで、dpkg が調べることではないということです。 dpkg がし
ないといけないことは、現在の coherency や integrity の維持し、
その情報を提供することだと思います。

> =   この利点は hoge のプロセスがどこで動いていようが
> =   構わなくすることもでき、エージェント化などと組み合わせれば非同期で、
> =   より多彩な設定プロセスを行うことをできるようにすることも可能です。
> 
> 「hogeのプロセス」の具体例として{pre,post}{inst,rm}を想定なさっ
> ているのなら、これらは明白に位置依存だと思います。必然的に、

「できるようにすることも可能です」なので、今のシステムでできるという
ことではないです。あくまでも、パッケージ側のプロセスがそのような
動作をするすることが実現できるということです。


> appletなどのような機種依存の無い実行イメージをダウンロードする
> ことになりますが、そのときに、
> 
> =   ルールと制御を分けるという話もありますが、カプセル化の方がずっと自然だと
> =   思います。
> 
> 自然かどうかは何をカプセル化したかにもよるので、パッケージにど
> のような自律性があるとどう便利なのかというのが見えないとなんと
> も申し上げられませんが。

#ここでいうカプセル化とは単なるデータの隠蔽ではなくて
#メソッドとデータをまとめたオブジェクトを構成すること
#ですが…念のため。

例えばあるホストのシステム状態を管理するサーバを dpkgd、
パッケージのインストール側はパッケージのインストール作業
をうけもつ多態性のあるエージェントを dpkg-agent とします。
ユーザがパッケージをインストールしたい場合

ユーザ： 「ホスト A, B, C に hoge をインストールしたい」
dpkg-agent : dpkg-agent は hoge 実行用のインスタンス
             になって、ホスト A にいく。
dpkg-agent: 「えーと、 hoge をインストールしたいんだけど
              foo はインストールされてて、bar は削除されてる？」
dpkgd (A) : 「はい」
dpkg-agent: 「じゃあ、展開してね」
dpkgd (A) : 「しました」
dpkg-agent: 「そしたら、 hogeconfig を実行してね」
dpkgd (A) : 「しました」
dpkg-agent: A へのインストール完了、B にいく。
dpkg-agent: 「えーと、 hoge をインストールしたいんだけど
              foo はインストールされてて、bar は削除されてる？」
dpkgd (B) : 「あ、 foo がもう入ってるよ」
dpkg-agent: 「了解」
dpkg-agent: ホスト B、依存関係エラー。 C にいく。
dpkg-agent: 「えーと、 hoge をインストールしたいんだけど
              foo はインストールされてて、bar は削除されてる？」
dpkgd (C) : 「はい」
dpkg-agent: 「じゃあ、展開してね」
dpkgd (C) : 「えーと、設定ファイルがすでに更新されてますね」
dpkg-agent: 「了解」
            A(完了)、B(エラー)、C(設定ファイル更新済)の情報を持って
            ユーザのところに帰る。
ユーザ    : 「A は削除して、C は前の設定ファイルを残してください」

(あと続く)

とかすると、ネットワーク上のいろいろなシステムを同時に管理でき
て便利だとか、現在は依存関係にエラーがあると問答無用で依存関係
にエラーがあるという状態にして終了してしまいますが、このへんの
処理もパッケージ側で多態性をもたせられるようになる(例えばある
パッケージは依存関係がエラーなら purge する等)とか、 ネット上に
あるパッケージインストールエージェント SE がいて、そいつに欲しい
というとネットワーク上からやってきて、そのシステムにインストール
をしてくれるとかいろいろあると思います。

> =   また、 preinst等 が shell script なのがあれだというのもありますが、
> =   それは、たまたま shell script がユーザ可読なので、ずいぶん手抜きだという
> =   風に感じてしまうというのがあると思います。
> 
> えと、私はそういう話はしていないし、岡さんもそういう論点ではお
> 話しされていないと思うんですが。

えーと、これはちょっと語弊でした。「手抜きにみえる」ではなくて
「手抜きにみえるようにもみえる」でしょうか？一見柔軟性がありす
ぎるように見えて、diversion は dpkg-divert を呼ばなといけない
という制限があるわけで、実装の方法には関係ないはずが、shell に
なってみると、どうとでもできてしまうという風に感じるということ
です。dpkg から渡って来るインタフェースもしっかり決まってて、
dpkg に渡すインタフェースもしっかり決まっているのだから、その
仕様に従えばシステム管理の一貫性は保てると思います。

それを preinst の存在をしった時に「だめじゃん」と思うのは
、dpkg にそのような機能がないから、shell script で管理側の
一貫性を無視して勝手にやる行為を提供することだという風にとれ
たのですが、違ってたらごめんなさい。

> ＃あと、オーバヘッドというのは何のことについておっしゃっていま
> 　すか？「実行速度」や「システムリソースの一時的消費」のことで
> 　はないとは思っていますが。

パッケージ側が知っていることを、パッケージ側が行わないで
管理側に調べさせることです。 3つ4つなら良いですが、
1000 や 2000(?) になった場合の無駄は相当なものです。
#しかも、あるパッケージで必要な操作は多くたって
#その半分にも満たないと思います。

#ちなみに、この辺の話はオーバヘッドがどうとかいう話は
#二の次です。
----
樽石 将人 電気通信大学情報工学科 3 年
 taruis-m@xxxxxxxxxxxxx               
 taru@debian.org, taru@debian.or.jp