[debian-users:12137] Re: historical info

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

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

# 風呂に入ったら回復したのでもうひと頑張り。


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

樽石> クライアント側にたよる設計とはこの場合、/var/lib/dpkg/diversion 
樽石> を sed などで勝手にいじることであって、 dpkg パッケージの一部であ
樽石> る dpkg-divert というインタフェースを通して実行する方式はサーバ
樽石> 側の管理している情報をサーバがきちんと仕事をしていると言えないでしょうか？

クライアントとサーバが何を意味しているのかようやく分かりまし
た。この場合、顧客(client)と供給者(supprier)と言うともうちょっ
とよく分かります(Object-oriented Software Construction より)。

# sed ... は、顧客がインタフェースを介さず直接オブジェクトの
  内部状態にアクセスする行為ですね。


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

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

ちょっと横槍を入れてみます。Ken N. さんは、Debian システムに
クラス不変表明みたいなものの必要性を描いていて、信頼性のため
に一番低いレイヤでこれを実装すべきだと唱えているんだと思いま
す。樽石さんは、dpkg はそこまで複雑にすべきではない、パッケー
ジで指定できる筈だと言ってるんだと思います。

僕はと言うと、以前は Ken N. さん寄りだったんですが、Debian
はそこまで完璧ではないことを知って、むしろ完全性を維持しよう
という行為がシステムを脆くする事に気がつきました。どんなにシ
ステムが正しさを維持しようとしても、アプリケーションレベルで
システムの状態破壊が起きる可能性が充分考えられるからです。正
常な状態が壊れた時、システムは自分を維持できなくなります。
dpkg が単なるインストール/アンインストールという極めて単純な
メカニズムにしておけば、容易に状態修復が行えます。ですが普通
はこれを使わないようにしておけばいいのです。そのかわり apt
のように依存関係を推論するインタフェースを被せることで dpkg
を安全に扱うことができます。樽石さんが言うようにパッケージが
やる仕事でもないと思うのです(そもそも静的に解決できない事が
多すぎて成立しない、これを preinst に押し込めるのは、先にも
書いたように見苦しすぎる、と)。

# apt は状態回復能力すら備えています。


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

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

そうではなくて、むしろ各々のパッケージの preinst あたりでイ
ンストールのための事前条件の検証を行う方が無駄が多いし、失敗
も多いです(例え便利なツールに*依存*したとしても)。


ソースパッケージは自己の情報を的確に記述するだけでいいのです。
パッケージビルドツールはそれを元に、静的に解決できる問題を解
いてバイナリパッケージを作成します。このバイナリパッケージに
も事前条件等の情報が記述されているだけで、手続きは一切含みま
せん(ここがポイントかつ難所)。

apt によるインストールは、事前条件を調べて、必要ならそれを充
足するように善処します。不可能なら当然失敗です。見通しが立て
ば、dpkg 系のツールを介してシステムの状態を調整します。それ
からインストールします。

dpkg によるインストールは、手作業で依存関係等を含む事前条件
を満たさなければなりませんが、同じ手順を踏む筈です。

ここで当然疑問があるでしょう、menu システムや emacsen や
info やバイトコンパイルが必要なものはどうやって処理するのか。
答えはいかにもオブジェクト指向的です。
それぞれの(menu等の)システムが、dpkg システムに対して、イン
タンスを登録するのです。この登録メカニズムだけは dpkg にプリ
ミティブにインプリメントされています。インスタンスは特定のイ
ンタフェースに準拠します。各バイナリパッケージはmenuを使うな
ら使う事と必要な情報を記述するだけでよく、それ以上は無用です。
各ソースパッケージはと言うと、もっと簡単で、そのパッケージの
特性を記述するだけでいいのです。特性を元にパッケージビルドツー
ルが menu が必要だとかいう事を推論して特定します。

考えているのはこんな所です。今の Debian からではちょっと厳し
い部分も多々ありますが...。
--
岡 充 (Mitsuru Oka)
高知大学理学部情報科学科4回生