[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Packaging Manual ch-conffiles, chap9

芳尾です。

Packaging Manual の 第9章が訳しおわりました。
よろしければ、目を通してみて変な箇所を見つけてくださったら嬉しいです。
#最近、日本語に自信がないんです。

つづけて、私は、第 10、11 章のほうの訳に移ります。
これは短いので、すぐ終わると思います。

栗栖さん、ホームページの更新のほうをよろしくお願いします。

ではでは。 ---- Yours, K.S.Yoshio
                mailto:shishamo@xxxxxxxxxxxxxxx
                http://www2.osk.3web.ne.jp/~shishamo


<html><head>
<title>
<!-- 
Debian Packaging Manual - Configuration file handling</title>
--> 
Debian Packaging Manual - パッケージ構成ファイルの運用</title>
<link rev=made href="mailto:ijackson@xxxxxxxxxxxxxx";>
</head><body>
<h1>
<!-- 
Debian Packaging Manual - chapter 9<br>
Configuration file handling
--> 
Debian Packaging Manual - 第 9 章<br>
パッケージ構成ファイルの運用
</h1>

<!-- 
<kbd>dpkg</kbd> can do a certain amount of automatic handling of package
configuration files.<P>
--> 

<kbd>dpkg</kbd> はあらゆる種類のパッケージ構成ファイルの自動操作を行ない
ます。<p>

<!-- 
Whether this mechanism is appropriate depends on a number of factors,
but basically there are two approaches to any particular configuration
file.<P>
--> 

そのメカニズムが妥当かどうかは、多数の要因によります。けれども、基本的に
はある特定の設定ファイルに対して二つのアプローチがあります。<p>

<!-- 
The easy method is to ship a best-effort configuration in the package,
and use <kbd>dpkg</kbd>'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.<P>
-->

簡単な方法は、パッケージ中に最良のパッケージ構築ファイルを含んでパッケー
ジを出荷することです。この場合は、更新作業を行うのに、<kbd>dpkg</kbd> の
構成ファイルメカニズムを使用します。ユーザが設定ファイルをいじらなくても、
パッケージの構築が問題なくできなければいけません。そして、そのパッケージ
の新しいバージョンはそんなに頻繁には出荷されません。これはよいアプローチ
です。<p>

<!-- 
The hard method is to build the configuration file from scratch in the
<kbd>postinst</kbd> 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.
-->

より複雑な方法として、構築ファイル (configuration file) を、
<kbd>postinst</kbd>スクリプト中にスクラッチから構築する方法があります。
そして、パッケージの初期のバージョンからのバグをその中で自動的にフィック
スしていくようにします。これは、構成ファイルがそれぞれのシステムによって
違う場合に使用される方法です。

<hr>
<h2><A name="s9.1">
<!-- 
9.1 Automatic handling of configuration files by <kbd>dpkg</kbd>
--> 
9.1 <kbd>dpkg</kbd> による構築ファイルの自動操作
</A></h2>

<!-- 
A package may contain a control area file called <code>conffiles</code>.  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.<P>
--> 

パッケージは、<code>conffiles</code> と呼ばれるコントロール制御ファイル
を含みます。このファイルは、自動構築のための設定ファイル名のリストで、改
行によって区切られます。リストされるファイル名は、絶対パスでなければいけ
ません。そして、参照されるファイルはパッケージ中に含まれていなければいけ
ません。<p>

<!-- 
When a package is upgraded <kbd>dpkg</kbd> will process the configuration
files during the configuration stage, shortly before it runs the
package's <kbd>postinst</kbd> script,<P>
--> 

パッケージが更新されるとき、<kbd>dpkg</kbd> は、設定ファイルの構成ステー
ジにおいて、設定ファイルを処理します。これは、<kbd>postinst</kbd> スクリ
プトが実行される直前ということになります。<p>

<!-- 
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.<P>
--> 

それぞれのファイルについて、<kbd>dpkg</kbd> は、パッケージに含まれるファ
イルのバージョンが以前のものと同一であるかどうかをチェックします。はまた、
現在システムにインストールされているパッケージのバージョンと最新のバージョ
ンとの比較も行います。<p>

<!-- 
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 - ie, 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.<P>
--> 

ユーザかパッケージ管理者のどちらがが設定ファイルを変更していない場合は、
設定ファイルはそのままインストールされます。どちらかが以前のバージョンの
設定ファイルを編集していた場合は、その編集されたバージョンが優先されます。
つまり、ユーザが設定ファイルを編集しており、パッケージ管理者が違ったバー
ジョンを出していなかったなら、ユーザの変更はそのまま残されます。けれども、
パッケージ管理者が新しいバージョンを出していて、ユーザが設定ファイルに手
を加えていなかった場合は、新しいバージョンがインストールされます(このと
き、そのことを知らせるメッセージも表示されます)。ユーザもパッケージ管理
者も両方が設定ファイルを変更していた場合は、ユーザが自分自身でこの問題を
解決するように、入力を促すプロンプトを出力します。<p>

<!-- 
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.<P>
--> 

この比較は、ファイル中の MD5 メッセージを計算することによって行なれます。
そして、そのインストールされた最新バージョンのファイル中の MD5 を同様に
保存します。

<!-- 
When a package is installed for the first time <kbd>dpkg</kbd> will install
the file that comes with it, unless that would mean overwriting a file
already on the filesystem.<P>
--> 

そのパッケージのインストールが初めてだったときは、<kbd>dpkg</kbd> は、そ
のファイルが、現存システムのファイルを上書きするものでないかぎり、そのま
まインストールします。<p>

<!-- 
However, note that <kbd>dpkg</kbd> 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.<P>
--> 

 けれども、<kbd>dpkg</kbd> は、ユーザまたはスクリプトによって削除された
設定ファイルを上書きすることはしません。いくつかのプログラムにおいては、
ある設定ファイルが、存在しないことによって、一定の効果をねらっているもの
があります。それは他の方法では実現できません。それ故、もしユーザがそうし
たのであれば、削除されたファイルはそのままにしておく必要があります。
<p>

<!-- 
Note that a package should <em>not</em> modify a <kbd>dpkg</kbd>-handled
conffile in its maintainer scripts.  Doing this will lead to
<kbd>dpkg</kbd> giving the user confusing and possibly dangerous options
for conffile update when the package is upgraded.
--> 

パッケージは、パッケージ管理者のスクリプトに含まれる、<kbd>dpkg</kbd> に
よって操作される conffile を変更することはできません。もし、これをした場
合、パッケージのアップデートのとき、<kbd>dpkg</kbd> は、ユーザを混乱させ
る、また潜在的に危険なオプションを与えることになります。

<hr>
<h2><A name="s9.2">
<!-- 
9.2 Fully-featured maintainer script configuration handling
--> 
9.2 管理スクリプトの設定
</A></h2>

<!-- 
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 <kbd>postinst</kbd> script.<P>
--> 

ホスト名やネットワークの詳細など、サイト依存の情報をファイルが含むといき、
パッケージの <kbd>postinst</kbd> スクリプトによって、そのファイルを作成
するのがよいでしょう。
<p>

<!-- 
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.<P>
--> 

たいてい、この場合、その値を決定するのに、システムの他の部分の状態やその
他の情報が必要となります。そしてその情報が得られないときは、プロンプトを
出力して、ユーザに情報を入力してもらうことになります。<p>

<!-- 
When using this method there are a couple of important issues which
should be considered:<P>
--> 

この方法を使用するとき、いくつか考慮しなければいけない重要なことがありま
す。<p>

<!-- 
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.<P>
--> 

設定ファイルを生成するプログラムにバグを発見したばあい、またそのファイル
のフォーマットが以前のバージョンから変更されたとき、postinst スクリプト
を編集しなければならなくなるでしょう。ふつう、この場合は、インストールさ
れた設定ファイルから、問題をとりのぞくことになるか、そのファイルのフォー
マットを変更することになります。気をつけなければいけません。すでにユーザ
はその問題に対処するように設定ファイルを更新しているかもしれません。スク
リプトはすでに対処済みである場合を検出して、正しくそれを扱わなければなり
ません。<p>

<!-- 
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
<code>/usr/sbin</code>, by convention called <code></code><var>package</var><code>config</code> and
then run that if appropriate from the post-installation script.  The
<code></code><var>package</var><code>config</code> 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 <code>--force</code> flag to
overwrite it.
--> 

設定ファイルの生成を<code>/usr/sbin</code> に置かれる別のプログラムにま
かせるというのは、よい考えです。このプログラム名は慣習として、
<code></code><var>package</var><code>config</code>となっており、パッケー
ジのインストール後に postinst スクリプトから実行されます。この
<code></code><var>package</var><code>config</code> プログラムは、ユーザ
に問合せることなしに既存の設定を上書きしてはいけません。上書きする場合は、
そのパッケージのセットアップが初めての場合(その後、任意の再構成が行われ
ることが多い)です。スクリプトは、設定ファイルが存在するかどうかをチェッ
クしなければいけません。そして上書きするためには、dpkg に、
<code>--force</code> オプションが与えられていなければいけません。

<hr>
Debian Packaging Manual
- <A href="index.html#copyright">Copyright .Aゥ1996 Ian Jackson.</A>*B
<br>
<A href="index.html#toc">Contents</A>; <A href="index.html#abstract">abstract</A>; <A href="ch-alternatives.html">next</A>; <A href="ch-relationships.html">back</A>.
<br>
Ian Jackson <A
href="mailto:ijackson@xxxxxxxxxxxxxx";>ijackson@xxxxxxxxxxxxxx</A><br>
Revised: David A. Morris <A
href="mailto:bweaver@debian.org";>bweaver@debian.org</A><br>
Maintainer: Christian Schwarz <A href="mailto:schwarz@debian.org";>schwarz@debi
an.org<br></A>
日本語訳：芳尾桂 <A
href="mailto:shishamo@xxxxxxxxxxxxxxx";>shishamo@xxxxxxxxxxxxxxx</A><br>
</address>
</body></html>
<h2><A name="s9.1">
<!-- 
9.1 Automatic handling of configuration files by <kbd>dpkg</kbd>
--> 
9.1 <kbd>dpkg</kbd> による構築ファイルの自動操作
</A></h2>
--
<h2><A name="s9.2">
<!-- 
9.2 Fully-featured maintainer script configuration handling
--> 
9.2 管理スクリプトの設定
</A></h2>