Packaging Manual 第９章

[HAYASE Shigenori <shayase@xxxxxxxxxxxxxxx>]

早瀬です。Packaging Manual 第９章 の作業が終りました。
翻訳のチェックをよろしくお願い致します。

-- 
早瀬 茂規 (shayase@xxxxxxxxxxxxxxx)

<!-- ORIG
    <chapt id="conffiles"><heading>Configuration file handling
 ORIG -->
    <chapt id="conffiles"><heading>パッケージ構成ファイルの運用
      </heading>

      <p>	
<!-- ORIG
	<prgn>dpkg</prgn> can do a certain amount of automatic
	handling of package configuration files.
 ORIG -->
	<prgn>dpkg</prgn> はある程度までは人手介入なしに
	パッケージ構成ファイルを操作できます。
      </p>

      <p>	
<!-- ORIG
	Whether this mechanism is appropriate depends on a number of
	factors, but basically there are two approaches to any
	particular configuration file.
 ORIG -->
	そのメカニズムが妥当かどうかは、多数の要因によります。けれども、
	基本的にはある特定の設定ファイルに対して二つのアプローチが
	あります。
      </p>

      <p>	
<!-- ORIG
	The easy method is to ship a best-effort configuration in the
	package, and use <prgn>dpkg</prgn>'s conffile mechanism to
	handle updates.  If the user is unlikely to want to edit the
	file, but you need them to be able to without losing their
	changes, and a new package with a changed version of the file
	is only released infrequently, this is a good approach.
 ORIG -->
	簡単な方法は、パッケージ中にできうる限り最良のパッケージ
	設定ファイルを含んだ形でリリースし、以降の更新には
	<prgn>dpkg</prgn> の構成ファイルメカニズムを使用することです。
	設定ファイルをユーザが編集することがなさそうでも、仮に
	編集していた場合にはその編集が失われないようにしたい、
	またはそのパッケージの新しいバージョンはそんなに頻繁には
	リリースされない、そんな場合にはこれはよいアプローチです。
      </p>

      <p>	
<!-- ORIG
	The hard method is to build the configuration file from
	scratch in the <prgn>postinst</prgn> script, and to take the
	responsibility for fixing any mistakes made in earlier
	versions of the package automatically.  This will be
	appropriate if the file is likely to need to be different on
	each system.
 ORIG -->
	より複雑な方法として、設定ファイルを、
	<prgn>postinst</prgn> スクリプト中でスクラッチから構築する方法が
	あります。そして、パッケージの初期のバージョンからのバグを
	その中で自動的にフィックスしていくようにします。これは、
	構成ファイルがそれぞれのシステムによって違う場合に使用される
	方法です。
      </p>
	
<!-- ORIG
      <sect><heading>Automatic handling of configuration files by
      <prgn>dpkg</prgn>
 ORIG -->
      <sect><heading><prgn>dpkg</prgn> による設定ファイルの自動操作
	</heading>

	<p>	  
<!-- ORIG
	  A package may contain a control area file called
	  <tt>conffiles</tt>.  This file should be a list of filenames
	  of configuration files needing automatic handling, separated
	  by newlines.  The filenames should be absolute pathnames,
	  and the files referred to should actually exist in the
	  package.
 ORIG -->
	  パッケージは、<tt>conffiles</tt> と呼ばれるコントロール制御
	  ファイルを含みます。このファイルは、改行によって区切られた、
	  自動設定のための設定ファイル名のリストです。リストされる
	  ファイル名は、絶対パスでなければいけません。また、
	  参照されるファイルはパッケージ中に含まれていなければ
	  いけません。
	</p>

	<p>	  
<!-- ORIG
	  When a package is upgraded <prgn>dpkg</prgn> will process
	  the configuration files during the configuration stage,
	  shortly before it runs the package's <prgn>postinst</prgn>
	  script,
 ORIG -->
	  パッケージが更新されるとき、<prgn>dpkg</prgn> は、
	  設定の段階において、設定ファイルを処理します。設定の段階とは、
	  <prgn>postinst</prgn> スクリプトを実行する直前です。
	</p>

	<p>	  
<!-- ORIG
	  For each file it checks to see whether the version of the
	  file included in the package is the same as the one that was
	  included in the last version of the package (the one that is
	  being upgraded from); it also compares the version currently
	  installed on the system with the one shipped with the last
	  version.
 ORIG -->
	  <prgn>dpkg</prgn> は、それぞれの設定ファイルについて、
	  パッケージに含まれているものが現在のバージョン
	  (つまり、今アップグレードしようとしている) のパッケージに
	  最初に含まれていたものと同一のものであるかをチェックします。
	  同時に、現在のバージョンのパッケージで最初に
	  提供されていたものと，現在システムにインストール
	  されているものとの比較も行います。
	</p>

	<p>	  
<!-- ORIG
	  If neither the user nor the package maintainer has changed
	  the file, it is left alone.  If one or the other has changed
	  their version, then the changed version is preferred - i.e.,
	  if the user edits their file, but the package maintainer
	  doesn't ship a different version, the user's changes will
	  stay, silently, but if the maintainer ships a new version
	  and the user hasn't edited it the new version will be
	  installed (with an informative message).  If both have
	  changed their version the user is prompted about the problem
	  and must resolve the differences themselves.
 ORIG -->
	  ユーザとパッケージ管理者のどちらがもが設定ファイルを
	  変更していない場合は、設定ファイルはそのまま
	  インストールされます。どちらかが以前のバージョンの
	  設定ファイルを編集していた場合は、その編集された
	  バージョンが優先されます。つまり、ユーザが設定ファイルを
	  編集しており、パッケージ管理者が違ったバージョンを
	  出していなかったなら、何の報告も無しに、ユーザの変更が
	  そのまま残されます。けれども、パッケージ管理者が新しい
	  バージョンを出していて、ユーザが設定ファイルに手を加えて
	  いなかった場合は、新しいバージョンがインストールされます
	  (このとき、そのことを知らせるメッセージも表示されます)。
	  ユーザもパッケージ管理者も両方が設定ファイルを変更していた
	  場合は、ユーザが自分自身でこの問題を解決するように、入力を
	  促すプロンプトを出力します。
	</p>

	<p>	  
<!-- ORIG
	  The comparisons are done by calculating the MD5 message
	  digests of the files, and storing the MD5 of the file as it
	  was included in the most recent version of the package.
 ORIG -->
	  この比較は、ファイル中の MD5 メッセージを計算することに
	  よって行なれます。そして、そのインストールされた
	  最新バージョンのファイル中の MD5 を同様に保存します。
	</p>

	<p>	  
<!-- ORIG
	  When a package is installed for the first time
	  <prgn>dpkg</prgn> will install the file that comes with it,
	  unless that would mean overwriting a file already on the
	  filesystem.
 ORIG -->
	  そのパッケージのインストールが初めてだったときは、
	  <prgn>dpkg</prgn> は、そのファイルが、現存システムの
	  ファイルを上書きするものでないかぎり、そのまま
	  インストールします。
	</p>

	<p>	  
<!-- ORIG
	  However, note that <prgn>dpkg</prgn> will <em>not</em>
	  replace a conffile that was removed by the user (or by a
	  script).  This is necessary because with some programs a
	  missing file produces an effect hard or impossible to
	  achieve in another way, so that a missing file needs to be
	  kept that way if the user did it.
 ORIG -->
	  けれども、<prgn>dpkg</prgn> は、ユーザまたはスクリプトに
	  よって削除された設定ファイルを上書きすることは
	  <em>ありません</em>。いくつかのプログラムにおいては、
	  ある設定ファイルが、存在しないことによって、他の方法では
	  代替できないような効果をねらっているものがあります。
	  したがって、もしユーザがそうしたのであれば、削除された
	  ファイルはそのままにしておく必要があります。
	</p>

	<p>	  
<!-- ORIG
	  Note that a package should <em>not</em> modify a
	  <prgn>dpkg</prgn>-handled conffile in its maintainer
	  scripts.  Doing this will lead to <prgn>dpkg</prgn> giving
	  the user confusing and possibly dangerous options for
	  conffile update when the package is upgraded.</p>
 ORIG -->
	  パッケージは、パッケージ管理スクリプトの中では、
	  <prgn>dpkg</prgn> によって操作される conffile を変更することは
	  <em>できません</em>。もし、これをした場合、パッケージの
	  アップデートのとき、<prgn>dpkg</prgn> は、ユーザを混乱させる、
	  また潜在的に危険なオプションを与えることになります。
      </sect>
	
<!-- ORIG
      <sect><heading>Fully-featured maintainer script configuration
      handling
 ORIG -->
      <sect><heading>管理スクリプトによる設定の取扱い
	</heading>

	<p>	  
<!-- ORIG
	  For files which contain site-specific information such as
	  the hostname and networking details and so forth, it is
	  better to create the file in the package's
	  <prgn>postinst</prgn> script.
 ORIG -->
	  ホスト名やネットワークの詳細など、サイト依存の情報を含む
	  ファイルは，パッケージの <prgn>postinst</prgn> スクリプトに
	  よって、そのファイルを作成するのがよいでしょう。
	</p>

	<p>	  
<!-- ORIG
	  This will typically involve examining the state of the rest
	  of the system to determine values and other information, and
	  may involve prompting the user for some information which
	  can't be obtained some other way.
 ORIG -->
	  たいてい、値や他の情報を決定するのに、システムの他の部分の
	  状態が必要となります。そして、その情報が得られないときは、
	  プロンプトを出力して、ユーザに情報を入力してもらうことに
	  なります。
	</p>

	<p>	  
<!-- ORIG
	  When using this method there are a couple of important
	  issues which should be considered:
 ORIG -->
	  この方法を使用するとき、いくつか考慮しなければいけない重要な
	  ことがあります。
	</p>

	<p>	  
<!-- ORIG
	  If you discover a bug in the program which generates the
	  configuration file, or if the format of the file changes
	  from one version to the next, you will have to arrange for
	  the postinst script to do something sensible - usually this
	  will mean editing the installed configuration file to remove
	  the problem or change the syntax.  You will have to do this
	  very carefully, since the user may have changed the file,
	  perhaps to fix the very problem that your script is trying
	  to deal with - you will have to detect these situations and
	  deal with them correctly.
 ORIG -->
	  設定ファイルを生成するプログラムにバグを発見した場合や、
	  または、そのファイルのフォーマットが以前のバージョンから
	  変更されたとき、postinst スクリプトを編集しなければ
	  ならなくなるでしょう。ふつう、この場合は、インストールされた
	  設定ファイルから、問題をとりのぞくことになるか、そのファイルの
	  文法を変更することになります。これは、気をつけて行わなくては
	  なりません。すでにユーザはその問題に対処するように
	  設定ファイルを更新しているかもしれません。スクリプトはすでに
	  対処済みである場合を検出して、正しくそれを扱わなければ
	  なりません。
	</p>

	<p>	  
<!-- ORIG
	  If you do go down this route it's probably a good idea to
	  make the program that generates the configuration file(s) a
	  separate program in <tt>/usr/sbin</tt>, by convention called
	  <tt><var>package</var>config</tt> and then run that if
	  appropriate from the post-installation script.  The
	  <tt><var>package</var>config</tt> program should not
	  unquestioningly overwrite an existing configuration - if its
	  mode of operation is geared towards setting up a package for
	  the first time (rather than any arbitrary reconfiguration
	  later) you should have it check whether the configuration
	  already exists, and require a <tt>−force</tt> flag to
	  overwrite it.</p></sect>
 ORIG -->
	  設定ファイルの生成を <tt>/usr/sbin</tt> に置かれる別の
	  プログラムにまかせるというのは、よい考えです。
	  このプログラム名は慣習として、
	  <tt><var>package</var>config</tt>となっており、適当なら、
	  パッケージの	  インストール後に postinst スクリプトから
	  実行されます。この
	  <tt><var>package</var>config</tt> プログラムは、ユーザに
	  問合せることなしに既存の設定を上書きしてはいけません。
	  もし、そのプログラムが (後に再設定行う場合ではなく)
	  初めてセットアップする場合には、そのプログラムは、
	  設定ファイルが存在するかどうかをチェックしなければいけません。
	  そして上書きするためには、dpkg に、<tt>--force</tt>
	  オプションが与えられていなければいけません。
	  </p></sect>
    </chapt>