[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ next ]
dpkg はパッケージ設定ファイルをある程度自動的に 操作できます。
そのメカニズムが妥当かどうかは、多数の要因によります。けれども、 基本的にはある特定の設定ファイルに対して二つのアプローチが あります。
簡単な方法は、パッケージ中にできうる限り最良のパッケージ
設定ファイルを含んだ形でリリースし、以降の更新には dpkg
の構成ファイルメカニズムを使用することです。
設定ファイルをユーザが編集することがなさそうでも、仮に
編集していた場合にはその編集が失われないようにしたい、
またはそのパッケージの新しいバージョンはそんなに頻繁には
リリースされない、そんな場合にはこれはよいアプローチです。
より複雑な方法として、設定ファイルを、 postinst
スクリプト中でスクラッチから構築する方法が
あります。そして、パッケージの初期のバージョンからのバグを
その中で自動的にフィックスしていくようにします。これは、
構成ファイルがそれぞれのシステムによって違う場合に使用される 方法です。
dpkg による設定ファイルの自動操作パッケージは、conffiles と呼ばれる制御 ファイルを含みます。このファイルは、自動操作を必要とする 設定ファイル名一覧です。設定ファイル名は、一行につきひとつの ファイルを絶対パスで書かれていなければいけません。また、 参照されるファイルはパッケージ中に含まれていなければ いけません。
パッケージが更新されるとき、dpkg は、
設定の段階において、設定ファイルを処理します。設定の段階とは、
postinst スクリプトを実行する直前です。
dpkg は、それぞれの設定ファイルについて、
パッケージに含まれているものが現在のバージョン
(つまり、今アップグレードしようとしている) のパッケージに
最初に含まれていたものと同一のものであるかをチェックします。
同時に、現在のバージョンのパッケージで最初に
提供されていたものと，現在システムにインストール
されているものとの比較も行います。
ユーザとパッケージ管理者のどちらがもが設定ファイルを 変更していない場合は、設定ファイルはそのまま インストールされます。どちらかが以前のバージョンの 設定ファイルを編集していた場合は、その編集された バージョンが優先されます。つまり、ユーザが設定ファイルを 編集しており、パッケージ管理者が違ったバージョンを 出していなかったなら、何の報告も無しに、ユーザの変更が そのまま残されます。けれども、パッケージ管理者が新しい バージョンを出していて、ユーザが設定ファイルに手を加えて いなかった場合は、新しいバージョンがインストールされます (このとき、そのことを知らせるメッセージも表示されます)。 ユーザもパッケージ管理者も両方が設定ファイルを変更していた 場合は、ユーザが自分自身でこの問題を解決するように、入力を 促すプロンプトを出力します。
この比較は、ファイル中の MD5 メッセージを計算することに よって行なれます。そして、そのインストールされた 最新バージョンのファイル中の MD5 を同様に保存します。
そのパッケージのインストールが初めてだったときは、 dpkg
は、そのファイルが、現存システムの
ファイルを上書きするものでないかぎり、そのまま インストールします。
けれども、dpkg は、ユーザまたはスクリプトに
よって削除された設定ファイルを上書きすることは
ありません。いくつかのプログラムにおいては、
ある設定ファイルが、存在しないことによって、他の方法では
代替できないような効果をねらっているものがあります。
したがって、もしユーザがそうしたのであれば、削除された
ファイルはそのままにしておく必要があります。
パッケージは、パッケージ管理スクリプトの中では、 dpkg
によって操作される conffile を変更することは
できません。もし、これをした場合、パッケージの
アップデートのとき、dpkg は、ユーザを混乱させる、
また潜在的に危険なオプションを与えることになります。
ホスト名やネットワークの詳細など、サイト依存の情報を含む
ファイルは，パッケージの postinst スクリプトに
よって、そのファイルを作成するのがよいでしょう。
たいてい、値や他の情報を決定するのに、システムの他の部分の 状態が必要となります。そして、その情報が得られないときは、 プロンプトを出力して、ユーザに情報を入力してもらうことに なります。
この方法を使用するとき、重要なことをいくつか考慮しなければ いけません。
設定ファイルを生成するプログラムにバグを発見した場合や、 または、そのファイルのフォーマットが以前のバージョンから 変更されたとき、postinst スクリプトを編集しなければ ならなくなるでしょう。ふつう、この場合は、インストールされた 設定ファイルから、問題をとりのぞくことになるか、そのファイルの 文法を変更することになります。これは、気をつけて行わなくては なりません。すでにユーザはその問題に対処するように 設定ファイルを更新しているかもしれません。スクリプトはすでに 対処済みである場合を検出して、正しくそれを扱わなければ なりません。
この方針を押し進めるならば、設定ファイルの生成を /usr/sbin に置かれる別のプログラムに まかせるというのは、よい考えです。このプログラム名は 慣習として、 packageconfigとなっており、適当なら、 パッケージの インストール後に postinst スクリプトから 実行されます。この packageconfig プログラムは、ユーザに 問合せることなしに既存の設定を上書きしてはいけません。 もし、そのプログラムが (後に再設定行う場合ではなく) 初めてセットアップする場合には、そのプログラムは、 設定ファイルが存在するかどうかをチェックしなければいけません。 そして上書きするためには、dpkg に、--force オプションが与えられていなければいけません。
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ next ]
Debian Packaging Manual
version revision 1.13, 2000-08-22ijackson@gnu.ai.mit.edubweaver@debian.orgschwarz@debian.orgsrivasta@debian.orgJ.D.Gilbey@qmw.ac.ukdebian-policy@lists.debian.orgshayase@tky3.3web.ne.jpdebian-doc@debian.or.jp