[debian-users:12159] Re: historical info

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

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


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

>  >例えば、パッケージにバグがあるとよく、次のバージョンの
>  >postinst あたりで対処したりしますが、あれが癌なんです。もっ
> 
>   これ、対処を次以降のバージョンでも維持するようルール化されているのでしょうか?
>   dpkg だけでバージョンアップをしていると、細めにバージョンアップをしていると
> 問題ないのが大きくアップすると失敗するという事が希にあります。
>   結局 /var/lib/dpkg の中を調べて手動で書き換えたりしているのですが...。

樽石> それはパッケージのバグですね。 Packaging Manual 6.3 をみれば
樽石> わかりますが、アップグレードされた場合は old-version がなんだったのか
樽石> わかるようになってます。

この辺りですね。まず{pre,post}{inst,rm}自体、パッケージのバ
グが生じやすい点、バグ修復のために次のバージョンから余計なも
のを書かなければならない点、やっぱりおかしいです。

lintian がある程度静的にパッケージの検査を行ってくれますが、
さすがに {pre,post}{inst,rm} を読むのは限界があります。パッ
ケージを ftp に upload する行為は、いわば、クラスの登録に似
ています。普通はコンパイラがチェックしてくれる厳格な検閲が必
要な部分です。だからこそ、{pre,post}{inst,rm} の部分は検査が
行える抽象フォーマットであって欲しいのです。

それでも、パッケージのバグはゼロにはならないでしょう。バグは
それ自体オブジェクトだと見ることができます(形こそはっきりし
ませんが)。バグが発見されて、それをどう除去するか。バグ専用
のデータベースが必要です。既知のバグとそのパッケージバージョ
ンと対処ルールとです。システムは何らかの機会にそのデータベー
スとパッケージを更新しますが、その時にバグがシステム中に存在
するかの検査を行います。存在すればバグオブジェクトとして登録
します。そして、パッケージのアップグレードに伴って、そのバグ
も消化するようにします。こうすれば、パッケージの中にバグ対処
プログラムをいつまでも残す必要は無くなります。

このデータベースはシステムに入っているパッケージのバージョン
を考慮して自身でバグ情報を掃除できるので、肥大化はしない筈で
す。
--
岡 充 (Mitsuru Oka)
高知大学理学部情報科学科4回生