[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Debian Policy Manual Chapter 4
かねこです。四章のチェックお願いします。
---------- >8 ---------- >8
<chapt>
<!-- <heading>Files</heading> -->
<heading>ファイル</heading>
<sect>
<!-- <heading>Binaries</heading> -->
<heading>バイナリファイル</heading>
<p>
<!-- It is not allowed that two packages install programs with
different functionality but with the same filenames. (The
case of two programs having the same functionality but
different implementations is handled via `alternatives.')
If this case happens, one of the programs has to be
renamed. The maintainers should report this to the
developers' mailing and try to find a consensus about
which package will have to be renamed. If a consensus can
not be reached, <em>both</em> programs must be
renamed.-->
二つのパッケージが、異なった機能を持つ同じ名前のプログラムを
インストールする事は許されていません。(二つのパッケージが同
じ機能を提供するが、その実装が異なっている場合には『代替
(alternatives)』機能を使って処理してください)。この場合には
一方のプログラムが名前を変更しなければなりません。メンテナは
名前が衝突していることを開発者のメーリングリストに報告して、
どちらのパッケージの名前を変更する方がいいのかの合意を得るよ
うにしてください。合意が得られない場合には、<em>両方の</em>
プログラムが名前を変更しなければなりません。</p>
<p>
<!-- Generally the following compilation parameters should be
used: -->
通常は以下記載のコンパイル時の引数を使ってください。
<example>
CC = gcc
<!-- CFLAGS = -O2 -g -Wall # sane warning options vary between
programs -->
CFLAGS = -O2 -g -Wall # warning オプションは変更可です。
<!-- LDFLAGS = # none -->
LDFLAGS = # なし
<!-- install -s # (or use strip on the files in debian/tmp) -->
install -s # または、debian/tmp で strip をかけてください。
</example></p>
<p>
<!-- Note that all installed binaries should be stripped,
either by using the <tt>-s</tt> flag to
<prgn>install</prgn>, or by calling <prgn>strip</prgn> on
the binaries after they have been copied into
<tt>debian/tmp</tt> but before the tree is made into a
package.-->
バイナリファイルは strip をかけなければならないことに留意し
てください。これは <prgn>install</prgn> の <tt>-s</tt> フラ
グか、パッケージツリーを作成する前にいったんプログラム
を <tt>debian/tmp</tt> に移して <prgn>strip</prgn> を呼び出
しておこなうかのどちらかで行ってください。
</p>
<p>
<!-- The <tt>-g</tt> flag is useful on compilation so that you
have available a full set of debugging symbols in your
built source tree, in case anyone should file a bug report
involving (for example) a core dump.
-->
<tt>-g</tt> はビルド環境のデバッグ情報を全部残しておけるため、
コンパイルオプションに指定しておくと後々役に立ちます。とりわ
け、誰かがコアダンプを含むバグレポートを送るような場合には。</p>
<p>
<!-- The <tt>-N</tt> flag should not be used. On a.out systems
it may have been useful for some very small binaries, but
for ELF it has no good effect.
-->
<tt>-N</tt> は使ってはいけません。a.out システムでは小さなバ
イナリの時に便利なこともあったのですが、ELF ではよい影響をあ
たえません。
</p>
<p>
<!-- It is up to the package maintainer to decide what
compilation options are best for the package. Certain
binaries (such as computationally-intensive programs) may
function better with certain flags (<tt>-O3</tt>, for
example); feel free to use them. Please use good judgment
here. Don't use flags for the sake of it; only use them
if there is good reason to do so. Feel free to override
the upstream author's ideas about which compilation
options are best--they are often inappropriate for our
environment.-->
コンパイルオプションに最も適したものを選ぶのはメンテナの判断
に任せています。ある種のバイナリ (たとえば計算量の多いプログ
ラム) にはそれなりのフラグ (<tt>-O3</tt> など) の方が実行時
の効率が上がるでしょうし、そういうときには自由にそのようなフ
ラグを使ってもかまいません。的確な判断を行ってください。漠然
とした考えでフラグを設定しないでください。そうする理由がある
ときのみに限ってください。どのコンパイルオプションが適切かに
ついての上流の作者の考えを変更するのは自由です -- しばしば私
たちの環境では適さないものが使われていますので。
</p></sect>
<sect>
<!-- <heading>Libraries</heading> -->
<heading>ライブラリ</heading>
<p>
<!-- All libraries must have a shared version in the lib
package and a static version in the lib-dev package. The
shared version must be compiled with <tt>-fPIC</tt>, and
the static version must not be. In other words, each
<tt>*.c</tt> file is compiled twice.-->
全てのライブラリは共有ライブラリ版の lib パッケージとスタテ
ィックライブラリ版の lib-dev パッケージを用意しなければいけ
ません。共有ライブラリバージョンは <tt>-fPIC</tt> オプション
付きでコンパイルし、スタティックライブラリバージョンではそう
してはいけません。言い替えれば、<tt>*.c</tt> は二度コンパイ
ルされることになります。</p>
<p>
<!-- You have to specify the gcc option <tt>-D_REENTRANT</tt>
when building a library (either static or shared) to make
the library compatible with LinuxThreads.-->
LinuxThreads と互換性を持ったライブラリ (スタティック、共有
の両方で) を作成するために、gcc のオプションに
<tt>-D_REENTRANT</tt> を指定しなければいけません。</p>
<p>
<!-- Note that all installed shared libraries should be
stripped with -->
インストールされる共有ライブラリは以下のように strip されて
いるべきです。
<example>
strip --strip-unneeded <your-lib>
</example>
<!-- (The option `--strip-unneeded' makes <tt>strip</tt> remove
only the symbols which aren't needed for relocation
processing.) Shared libraries can function perfectly well
when stripped, since the symbols for dynamic linking are
in a separate part of the ELF object file.-->
(このオプション `--strip-unneeded' は <tt>strip</tt> にリロケ
ーション処理に必要のないシンボルのみを削除するように指示します)
ダイナミックリンクの際に使用するシンボルは別の ELF オブジェク
トにあるので、共有ライブラリは strip されても完全に機能します。
</p>
<p>
<!-- Note that under some circumstances it may be useful to
install a shared library unstripped, for example when
building a separate package to support debugging.-->
ある種の場合、たとえばデバッグ機能を持った別パッケージを構築
する場合など、strip しない共有ライブラリを作成したほうがいい
場合もあることに気をつけてください。
</p>
<p>
<!-- An ever increasing number of packages are using libtool to
do their linking. The latest GNU libtools (>= 1.3a) can take
advantage of the metadata in the installed libtool archive
files (`*.la'). The main advantage of libtool's .la files is
that it allows libtool to store and subsequently access
metadata with respect to the libraries it builds. libtool
will search for those files, which contain a lot of useful
information about a library (e.g. dependency libraries for
static linking). Also, they're <em>essential</em> for
programs using libltdl.-->
リンク処理に libtool を使うパッケージが増えてきています。最新の
GNU libtools (>= 1.3a) ではインストールされた libtool アーカイブ
のファイル (`*.la') を活用できます。libtools の .la ファイルの主
な利点は作成するライブラリに準じた形でメタデータを格納し引き続い
て参照できることです。libtool はこれらのライブラリに関する豊富な
情報 (たとえばスタティックリンク時に依存関係にあるライブラリにつ
いて) を含むファイルを検索することができます。また、libltdl を使
うプログラムでは、libtools の使用は <em>必須</em>です。
<!-- libtool 関係、わかってないんであやしい -->
</p>
<p>
<!-- Certainly libtool is fully capable of linking against shared
libraries which don't have .la files, but being a mere shell
script it can add considerably to the build time of a
libtool using package if that shell-script has to derive all
this information from first principles for each library every
time it is linked. With the advent of libtool-1.4 (and to a
lesser extent libtool-1.3), the .la files will also store
information about inter-library dependencies which cannot
necessarily be derived after the .la file is deleted.-->
libtools は確かに .la を持たない共有ライブラリをリンクする機能
を一通り提供しますが、libtools はシェルスクリプトにすぎないので
リンクしようとする各ライブラリから初見で上記の情報を引き出そう
とするとパッケージの構築時間が目に見えて伸びることになります。
また、libtool-1.3 もある程度は同様の拡張がなされていますが
libtool-1.4 からは改良により .la ファイルの削除後に導き出せる
保証のないようなライブラリ間の依存関係に関する情報を .la ファ
イル中に保存するようになっています。
</p>
<p>
<!-- Packages that use libtool to create shared libraries must
include the <em>.la</em> files in the <em>-dev</em>
packages, with the exception that if the package relies on
libtool's <em>libltdl</em> library, in which case the .la
files must go in the run-time library package. This is a
good idea in general, and especially for static linking
issues.-->
というわけで、共有ライブラリを libtool を使って作成するパッケ
ージでは、<em>-dev</em> パッケージに <em>.la</em> ファイルを
含めてください。ただし、libtool の <em>libltdl</em> ライブラリ
に依存するパッケージは例外で、この場合には .la ファイルはラン
タイムパッケージに含めてください。後者のようにすることは通常
良いやり方で、特にスタティックリンク時の問題に対処するのが容易
になります。
</p>
<p>
<!-- Please make sure that you use only released versions of
shared libraries to build your packages; otherwise other
users will not be able to run your binaries
properly. Producing source packages that depend on
unreleased compilers is also usually a bad
idea.-->
自分のパッケージを作成する際にはリリース版の共有ライブラリのみ
を使うように気をつけてください。ここで間違えるとほかのユーザは
あなたのプログラムを正しく実行することができません。リリースさ
れていないコンパイラに依存するパッケージを作成することも通常好
ましくありません。
</p>
</sect>
<sect>
<!-- <heading>Shared libraries</heading> -->
<heading>共有ライブラリ</heading>
<p>
<!-- Packages involving shared libraries should be split up
into several binary packages.-->
共有ライブラリを含むパッケージは、いくつかのバイナリパッケージ
に分割しなければいけません。</p>
<p>
<!-- For a straightforward library which has a development
environment and a runtime kit including just shared
libraries you need to create two packages:
<tt><var>libraryname</var><var>soname</var></tt>
(<var>soname</var> is the shared object name of the shared
library--it's the thing that has to match exactly between
building an executable and running it for the dynamic
linker to be able run the program; usually the
<var>soname</var> is the major number of the library) and
<tt><var>libraryname</var><var>soname</var>-dev</tt>.
-->
開発環境とランタイムキットとして共有ライブラリのみを含む単純
な構成のパッケージでは、二つのパッケージを作成すべきです。即
ち、<tt><var>libraryname</var><var>soname</var></tt>
と <tt><var>libraryname</var><var>soname</var>-dev</tt> です。
(<var>soname</var> は共有ライブラリの共有オブジェクト名です。
これはプログラムの作成時とダイナミックリンカがプログラムを実
行する際に一致させなければならないもので、通常はライブラリの
メジャーバージョン番号です)
</p>
<p>
<!-- If you prefer only to support one development version at a
time you may name the development package
<tt><var>libraryname</var>-dev</tt>; otherwise you may
wish to use <prgn>dpkg</prgn>'s conflicts mechanism to
ensure that the user only installs one development version
at a time (after all, different development versions are
likely to have the same header files in them, causing a
filename clash if both are installed). Typically the
development version will also need an exact version
dependency on the runtime library, to make sure that
compilation and linking happens correctly.-->
開発版は一種類のみサポートすると決めたならば、開発用パッケージ
の名前は<tt><var>libraryname</var>-dev</tt> としてしまってかま
いません。そうでない場合には <prgn>dpkg</prgn> の conflict メ
カニズムを使って一種類の開発用パッケージのみ同時に存在するよう
に保証するのも良いでしょう (異なった開発用のパッケージといえど
も同じヘッダファイルを持つことが多いですから、結局二種以上を
インストールしようとするとファイル名衝突は起こりがちです)。通
常開発用のバージョンでは、正しくコンパイル・リンクを行うため
にランタイムライブラリに対して正確なバージョン依存関係を必要と
しています。
</p>
<p>
<!-- Packages which use the shared library should have a
dependency on the name of the shared library package,
<tt><var>libraryname</var><var>soname</var></tt>. When
the <var>soname</var> changes you can have both versions
of the library installed while moving from the old library
to the new.-->
共有ライブラリを使うパッケージは共有ライブラリパッケージ名に
すなわち、<tt><var>libraryname</var><var>soname</var></tt>
に対して依存関係を指定します。<var>soname</var> を変更して
旧ライブラリから新ライブラリへの移行期間中に両方のバージョン
をインストールしておくこともできます。</p>
<p>
<!-- If your package has some run-time support programs which
use the shared library you must <em>not</em> put them in
the shared library package. If you do that then you won't
be able to install several versions of the shared library
without getting filename clashes. Instead, either create
a third package for the runtime binaries (this package
might typically be named
<tt><var>libraryname</var>-runtime</tt>--note the absence
of the <var>soname</var> in the package name) or if the
development package is small include them in there.
-->
パッケージが共有ライブラリを使用する場合の実行時のサポートプロ
グラムをもつ場合、共有ライブラリパッケージにそれらを含めては
<em>いけません</em>。そのようにしてしまうと、ファイル名の衝突
を避けることなく、複数の共有ライブラリのバージョンをインストー
ルすることができません。この場合には代わりに、実行時のサポー
トのための三番目のパッケージ (そのパッケージ名は通常、
<tt><var>libraryname</var>-runtime</tt> とします。<var>soname
</var> がパッケージ名にないことに注意) を作成するか、開発用
パッケージが小さければそれに含めてください。</p>
<p>
<!-- If you have several shared libraries built from the same
source tree you can lump them all together into a single
shared library package, provided that you change all their
<var>soname</var>s at once (so that you don't get filename
clashes if you try to install different versions of the
combined shared libraries package).-->
同じソースツリーから複数の共有ライブラリをを構築する場合、そ
れらをまとめて一つの共有ライブラリパッケージにすることができ
ます。そのときにはこの集合ライブラリの複数のバージョンをイン
ストールした場合にファイル名の衝突が起きないように、
<var>soname</var> の変更は、このライブラリ集合の各ライブラリ
に対して一括して実施するようにしてください。
</p>
<p>
Follow the directions in the <em>Debian Packaging
Manual</em> for putting the shared library in its package,
and make sure you include a <tt>shlibs</tt> control area
file with details of the dependencies for packages which
use the library.
</p>
パッケージ中に共有ライブラリを含むに当たっては <em>Debian
Packaging Manual</em> の指示に従って、このライブラリを使う
パッケージのための依存関係の詳細を記載した <tt>shlibs</tt>
コントロールエリアファイルを含めたことを確認してください。
<p>
<!-- Shared libraries should <em>not</em> be installed
executable, since <prgn>ld.so</prgn> does not require this
and trying to execute a shared library results in a core
dump.-->
共有ライブラリに実行属性を着けてインストールしては <em>いけま
せん</em>。<prgn>ld.so</prgn> はこのような属性を必要としてい
ませんし、共有ライブラリを実行してもコアダンプを吐くだけです
から。
</p></sect>
<sect id="scripts">
<!-- <heading>Scripts</heading>-->
<heading>スクリプト</heading>
<p>
<!-- All command scripts, including the package maintainer
scripts inside the package and used by <prgn>dpkg</prgn>,
should have a <tt>#!</tt> line naming the shell to be used
to interpret them.-->
すべてのコマンドスクリプトは、これにはパッケージ中に含まれ
<prgn>dpkg</prgn> が使用するメンテナスクリプトも含まれますが、
スクリプトを解釈するインタープリタを <tt>#!</tt> 行を追加し
て指定しなければいけません。
</p>
<p>
<!-- In the case of Perl scripts this should be
<tt>#!/usr/bin/perl</tt>.-->
それが perl スクリプトの場合は、その行は
<tt>#!/usr/bin/perl</tt> でなければいけません。
</p>
<p>
<!-- Shell scripts (<prgn>sh</prgn> and <prgn>bash</prgn>)
should almost certainly start with <tt>set -e</tt> so that
errors are detected. Every script <em>must</em> use
<tt>set -e</tt> or check the exit status of <em>every</em>
command.-->
シェルスクリプト (<prgn>sh</prgn> や <prgn>bash</prgn> を使
う) では、特殊な場合をのぞいて最初に <tt>set -e</tt> を書い
てエラーを検出するようにしてください。スクリプトはすべて
<tt>set -e</tt> を使うか、<em>全</em>コマンドの終了ステータ
スを明示的に調べてエラーを検出しなければ<em>いけません</em>。</p>
<p>
<!-- The standard shell interpreter `<tt>/bin/sh</tt>' may be a
symbolic link to any POSIX compatible shell. Thus, shell
scripts specifying `<tt>/bin/sh</tt>' as interpreter may
only use POSIX features. If a script requires non-POSIX
features from the shell interpreter, the appropriate shell
has to be specified in the first line of the script (e.g.,
`<tt>#!/bin/bash</tt>') and the package has to depend on
the package providing the shell (unless the shell package
is marked `Essential', e.g., in the case of
<prgn>bash</prgn>).-->
標準のシェルインタープリタは `<tt>/bin/sh</tt>' で、これは
POSIX 互換なシェルへのシンボリックリンクになっています。従
って、`<tt>/bin/sh</tt>' をインタープリタに指定したシェルで
は POSIX 規定の機能だけを使ってください。スクリプトで POSIX
に規定されていない機能をインタープリタに期待する場合には、適
切なシェルを最初に指定 (例えば `<tt>#!/bin/bash</tt>' のよ
うに) して、パッケージからそのシェルに対して依存関係を与えて
ください (そのシェルパッケージが `Essential' 扱いになってい
る、例えば <prgn>bash</prgn> のような場合は依存関係の指定は
不要です)。
</p>
<p>
<!-- Restrict your script to POSIX features when possible so
that it may use <tt>/bin/sh</tt> as its interpreter. If
your script works with <prgn>ash</prgn>, it's probably
POSIX compliant, but if you are in doubt, use
<tt>/bin/bash</tt>.-->
スクリプトではできる限り POSIX 規定の機能だけを用いて書くよ
うにし、<tt>/bin/sh</tt> をインタープリタとして使えるように
してください。あなたのスクリプトが <prgn>ash</prgn> で動く
ならおそらく POSIX 互換になっていると思いますが、疑問がある
時には明示的に <tt>/bin/bash</tt> を使ってください。</p>
<p>
<!-- Perl scripts should check for errors when making any
system calls, including <tt>open</tt>, <tt>print</tt>,
<tt>close</tt>, <tt>rename</tt> and <tt>system</tt>.-->
Perl スクリプトでは、システムコールを使ったときにはエラーを
チェックしてください。システムコールには <tt>open</tt>、
<tt>print</tt>、<tt>close</tt>、<tt>rename</tt>、
<tt>system</tt> などが含まれます。</p>
<p>
<!-- <prgn>csh</prgn> and <prgn>tcsh</prgn> should be avoided
as scripting languages. See <em>Csh Programming
Considered Harmful</em>, one of the <tt>comp.unix.*</tt>
FAQs. It can be found on
<url id="http://language.perl.com/versus/csh.whynot";>, or
<url id="http://www.cpan.org/doc/FMTEYEWTK/versus/csh.whynot";>
or even on <ftpsite>ftp.cpan.org</ftpsite>
<ftppath>/pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot</ftppath>.
If an upstream package comes with <prgn>csh</prgn> scripts
then you must make sure that they start with
<tt>#!/bin/csh</tt> and make your package depend on the
<prgn>c-shell</prgn> virtual package.-->
<prgn>csh</prgn> や <prgn>tcsh</prgn> をスクリプト言語に使うの
は避けてください。理由は <tt>comp.unix.*</tt> の FAQ の一つ
<em>Csh Programming Considered Harmful</em> を参考にしてくださ
い。これは <url id="http://language.perl.com/versus/csh.whynot";>
や <url id="http://www.cpan.org/doc/FMTEYEWTK/versus/csh.whynot";>
で、場合によっては <ftpsite>ftp.cpan.org</ftpsite> の
<ftppath>/pub/perl/CPAN/doc/FMTEYEWTK/versus/csh.whynot</ftppath>
にあります。
<footnote>
訳注：日本語訳はとりあえず <ftpsite>ftp.sra.or.jp</ftpsite> の
<ftppath>/pub/news/fj.archives.documents/csh-whynot-jp</ftppath>
にあります。
<!-- ほかにもあるとは思うけど、すぐには見つからなかった。-->
</footnote>
上流のパッケージに <prgn>csh</prgn> スクリプトが含まれていると
きには、そのスクリプトが <tt>#!/bin/csh</tt> で始まり、その
パッケージを <prgn>c-shell</prgn> 仮想パッケージに依存するよう
設定したことをよく確認してください。
</p>
<p>
<!-- Any scripts which create files in world-writable
directories (e.g., in <tt>/tmp</tt>) have to use a
mechanism which will fail if a file with the same name
already exists.-->
誰からでも書けるディレクトリに (例えば <tt>/tmp</tt> に) フ
ァイルを作成するスクリプトは、作成しようとするファイルと同じ
名前のファイルが存在したら失敗するような機構を組み込んでくだ
さい。</p>
<p>
<!-- The Debian base distribution provides the
<prgn>tempfile</prgn> and <prgn>mktemp</prgn> utilities
for use by scripts for this purpose.-->
Debian の base ディストリビューションに含まれる
<prgn>tempfile</prgn> と <prgn>mktemp</prgn> ユーティリティ
はこの目的でスクリプト中で使うためのものです。
</p></sect>
<sect>
<!-- <heading>Symbolic links</heading> -->
<heading>シンボリックリンク</heading>
<p>
<!-- In general, symbolic links within a top-level directory
should be relative, and symbolic links pointing from one
top-level directory into another should be absolute. (A
top-level directory is a sub-directory of the root
directory `/'.)-->
通常、トップレベルディレクトリ (ルートディレクトリ `/' にあ
るディレクトリがトップレベルディレクトリです) 内のシンボリッ
クリンクは相対参照とします。また、トップレベルディレクトリ間
のシンボリックリンクは絶対参照とします。</p>
<p>
<!-- In addition, symbolic links should be specified as short
as possible, i.e., link targets like `foo/../bar' are
deprecated.-->
それに加えて、シンボリックリンクは可能な限り短くすべきです。
例えば `foo/../bar' のような参照はよろしくありません。</p>
<p>
<!-- Note that when creating a relative link using
<prgn>ln</prgn> it is not necessary for the target of the
link to exist relative to the working directory you're
running <prgn>ln</prgn> from; nor is it necessary to
change directory to the directory where the link is to be
made. Simply include the string that should appear as the
target of the link (this will be a pathname relative to
the directory in which the link resides) as the first
argument to <prgn>ln</prgn>.-->
<prgn>ln</prgn> を使って相対リンクを作成するときに、
<prgn>ln</prgn> を実行する作業用ディレクトリからの相対位置に
リンク先が存在している必要はありません。また、リンクを作成し
ようしているディレクトリに作成の際にディレクトリを移動する必
要もありません。やるべき事は単にリンク先 (リンクが存在するデ
ィレクトリからの相対参照になるようなパス名です) が
<prgn>ln</prgn> の最初の引数に現れるよう文字列を与えるだけで
す。</p>
<p>
<!-- For example, in your <prgn>Makefile</prgn> or
<tt>debian/rules</tt>, do things like: -->
例えば、<prgn>Makefile</prgn> や <tt>debian/rules</tt> で以下
のような処理を行ってください。
<example>
ln -fs gcc $(prefix)/bin/cc
ln -fs gcc debian/tmp/usr/bin/cc
ln -fs ../sbin/sendmail $(prefix)/bin/runq
ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
</example></p>
<p>
<!-- A symbolic link pointing to a compressed file should
always have the same file extension as the referenced
file. (For example, if a file `<tt>foo.gz</tt>' is
referenced by a symbolic link, the filename of the link
has to end with `<tt>.gz</tt>' too, as in
`bar.gz.')-->
圧縮されたファイルを参照するシンボリックリンクは対象ファイル
と同じ拡張子を持つようにしてください (例えば、`<tt>foo.gz</tt>'
をシンボリックリンクで参照する場合、リンクのファイル名も同様に
<tt>.gz</tt>' で終わる、`bar.gz' のような名前にしてください)。
</p></sect>
<sect>
<!-- <heading>Device files</heading> -->
<heading>デバイスファイル</heading>
<p>
<!-- No package may include device files in the package file
tree.-->
パッケージファイルツリーにデバイスファイルを含めることは許
されていません。</p>
<p>
<!-- If a package needs any special device files that are not
included in the base system, it has to call
<prgn>makedev</prgn> in the <tt>postinst</tt> script,
after asking the user for permission to do so.-->
パッケージが base システムに含まれていない特殊なデバイスファ
イルを必要とする場合には、<tt>postinst</tt> スクリプト中でユ
ーザに許可を問い合わせた後 <prgn>makedev</prgn> を呼び出して
ください。</p>
<p>
<!-- No package should remove any device files in the
<tt>postrm</tt> or any other script. This is left to the
system administrator.-->
<tt>postrm</tt> などのスクリプト中でデバイスファイルを削除し
てはいけません。そのような処置は管理者に任せてください。</p>
<p>
<!-- Debian uses the serial devices
<tt>/dev/tty*</tt>. Programs using the old
<tt>/dev/cu*</tt> devices should be changed to use
<tt>/dev/tty*</tt>.-->
Debian ではシリアルデバイスファイル名に <tt>/dev/tty*</tt>
を使います。昔の <tt>/dev/cu*</tt> を使っているプログラムは
<tt>/dev/tty*</tt> に変更すべきです。</p>
</sect>
<sect id="config files">
<!-- <heading>Configuration files</heading> -->
<heading>設定ファイル</heading>
<sect1>
<!-- <heading>Definitions</heading>-->
<heading>定義</heading>
<p>
<taglist>
<!-- <tag>configuration file</tag> -->
<tag>設定ファイル</tag>
<item><p>
<!-- A file that affects the operation of program, or
provides site- or host-specific information, or
otherwise customizes the behavior of program.
Typically, configuration files are intended to be
modified by the system administrator (if needed or
desired) to conform to local policy or provide more
useful site-specific behavior.-->
プログラムの実行に影響を与えるファイル、またはサイトや
ホスト固有の情報を提供するファイル、またはプログラムの
挙動を制御するためのファイルです。通常設定ファイルはシ
ステム管理者の手でローカルの方針やサイト個別要件にあわ
せた挙動をさせるために、必要に応じて変更されることを想
定しています。</p>
</item>
<tag><tt>conffile</tt></tag>
<item><p>
<!-- A file listed in a package's <tt>conffiles</tt>
file, and is treated specially by <prgn>dpkg</prgn>
(see the <em>Debian Packaging Manual</em>).-->
パッケージの <tt>conffiles</tt> ファイル中に列挙された
ファイルで、<prgn>dpkg</prgn> から特別の扱いを受けます。
(<em>Debian パッケージングマニュアル</em>参照)
</p>
</item>
</taglist>
</p>
<p>
<!-- The distinction between these two is important; they are
not interchangeable concepts. Almost all
<tt>conffiles</tt> are configuration files, but many
configuration files are not <tt>conffiles</tt>.-->
この二つの違いは重要で、置き換え可能な概念ではありません。ほ
とんどすべての <tt>conffiles</tt> は設定ファイルですが、多く
の設定ファイルは <tt>conffiles</tt> ではありません。</p>
<p>
<!-- Note that a script that embeds configuration information
(such as most of the files in <tt>/etc/init.d</tt> and
<tt>/etc/cron.{daily,weekly,monthly}</tt>) is de-facto a
configuration file and should be treated as such.-->
設定情報を内部に含むスクリプト (例えば <tt>/etc/init.d</tt>
のほとんどのファイルや、<tt>/etc/cron.{daily,weekly,monthly}</tt>
など) は事実上の設定ファイルですし、そのように扱われます。</p>
</sect1>
<sect1>
<!-- <heading>Location</heading> -->
<heading>配置</heading>
<p>
<!-- Any configuration files created or used by your package
should reside in <tt>/etc</tt>. If there are several you
should consider creating a subdirectory of <tt>/etc</tt>
named after your package.-->
パッケージによって作られ使われる設定ファイルは <tt>/etc</tt>
以下に配置しなければいけません。関連した設定ファイルが複数あ
る場合には、サブディレクトリの作成を検討してください。</p>
<p>
<!-- If your packages creates or uses configuration files
outside of <tt>/etc</tt>, and it is not feasible to modify
the package to use the <tt>/etc</tt>, you should still put
the files in <tt>/etc</tt> and create symbolic links to
those files from the location that the package
requires.-->
あなたのパッケージが <tt>/etc</tt> 以外の場所に設定ファイルを
作成し、かつそのパッケージが <tt>/etc</tt> を使うように修正す
るのが望ましくない場合でも、設定ファイル自体は <tt>/etc</tt>
に置き、パッケージの期待する場所からシンボリックリンクで参照
するようにしてください。</p>
</sect1>
<sect1>
<!-- <heading>Behavior</heading> -->
<heading>設定ファイルの扱い</heading>
<p>
<!-- Configuration file handling must conform to the following
behavior: -->
設定ファイルの扱いは以下の挙動に従ったものとしなければいけま
せん。
<list>
<item>
<!-- <p>local changes must be preserved during a package
upgrade</p> -->
<p>ローカルで行った変更は、パッケージアップグレードの時に
保持されていなければいけません。</p>
</item>
<item>
<!-- <p>configuration files should be preserved when the
package is removed, and only deleted when the
package is purged.</p> -->
設定ファイルはパッケージ削除の際には保存し、パッケージの
完全削除 (purge) の際にのみ削除するようにしなければいけ
ません。
</item>
</list></p>
<p>
<!-- The easy way to achieve this behavior is to make the
configuration file a <tt>conffile</tt>. This is
appropriate if it is possible to distribute a default
version that will work for most installations, although
some system administrators may choose to modify it. This
implies that the default version will be part of the
package distribution, and must not be modified by the
maintainer scripts during installation (or at any other
time).-->
この挙動を行わせるやさしい方法は設定ファイルを <tt>conffile
</tt> にしてしまうことです。これはほとんどのインストールの場
合にそのままで使え、一部のシステム管理者が変更するかもしれな
い、そういう設定ファイルを添付できる場合に適した方法です。
更に、この方法を使うためには標準設定のファイルがパッケージの
配布物に含まれていること、またインストール中 (やその他の際に)
にメンテナスクリプトから書き換えを行わない、という二条件を満
たしている必要があります。
</p>
<p>
<!-- The other way to do it is to via the maintainer scripts.
In this case, the configuration file must not be listed as
a <tt>conffile</tt> and must not be part of the package
distribution. If the existence of a file is required for
the package to be sensibly configured it is the
responsibility of the package maintainer to write scripts
which correctly create, update, maintain and
remove-on-purge the file. These scripts must be idempotent
(i.e. must work correctly if <prgn>dpkg</prgn> needs to
re-run them due to errors during installation or removal),
must cope with all the variety of ways <prgn>dpkg</prgn>
can call maintainer scripts, must not overwrite or
otherwise mangle the user's configuration without asking,
must not ask unnecessary questions (particularly during
upgrades), and otherwise be good citizens.-->
もう一つのやり方は、上記の挙動をメンテナスクリプトから実現す
る方法です。この場合には設定ファイルは <tt>conffile</tt> と
して列挙してはならず、またパッケージ配布物に含まれていてもい
けません。パッケージにまずまずの設定を行うために、なんらかの
設定ファイルが存在していることがもし必要ならば、設定ファイル
を作成し、更新し、維持し、完全削除の際に削除するのはすべてメ
ンテナスクリプトの責任です。このスクリプトは結果の再現性を持
たなければいけません (すなわち、<prgn>dpkg</prgn> がインスト
ール中のエラーや、パッケージの削除のためスクリプトを再実行し
た場合に正しく動作しなければならないということです)。また、こ
のスクリプトは <prgn>dpkg</prgn> がメンテナスクリプトを呼び出
す様々なやり方に対応できねばならず、ユーザの設定ファイルを前
もって問い合わせることなしに上書きしたり壊したりしてはいけま
せん。またこのスクリプトは、特にアップグレードの時には、不必
要な質問を行ったりせず、善良な市民として振る舞わなければいけ
ません。
</p>
<p>
<!-- The scripts need not configure every possible option for
the package, but only those necessary to get the package
running on a given system. Ideally the sysadmin should not
have to do any configuration other than that done
(semi-)automatically by the <tt>postinst</tt> script.-->
スクリプトは与えられたシステムでパッケージがまっとうに動作す
るに必要な設定を行えば良く、パッケージに設定しうるすべてのオ
プションを設定しなければならないわけではありません。理想的な
ことを言えば、システム管理者が <tt>postinst</tt> で(半)自動的
に行われた設定以外のことを行う必要がないのが、あるべき姿です。</p>
<p>
A common practice is to create a script called
<tt><var>package</var>-configure</tt> and have the
package's <tt>postinst</tt> call it if and only if the
configuration file does not already exist. In certain
cases it is useful for there to be an example or template
file which the maintainer scripts use. Such files should
be in <tt>/usr/share/doc</tt> if they are examples or
<tt>/usr/lib</tt> if they are templates, and should be
perfectly ordinary <prgn>dpkg</prgn>-handled files
(<em>not</em> <tt>conffiles</tt>).
通常取られる手法は <tt><var>package</var>-configure</tt>
という名のスクリプトを作成し、パッケージの <tt>postinst</tt>
から設定ファイルが存在していないときのみ、そのスクリプトを
呼ぶようにするやり方です。時にはメンテナスクリプトが使う例
や雛形ファイルを用意すると便利なこともあります。そのような
ファイルがある場合、それが例なら <tt>/usr/share/doc</tt> へ、
雛形なら <tt>/usr/lib</tt> 以下に置き、通常の
<prgn>dpkg</prgn> で処理するファイルにして (すなわち、
<tt>conffile</tt> では<em>無いようにする</em>) ください。
</p>
<p>
<!-- These two styles of configuration file handling <em>must
not be mixed</em>, for that way lies madness:
<prgn>dpkg</prgn> will ask about overwriting the file
every time the package is upgraded.-->
これまで説明してきた設定ファイルの扱いの手法は <em>混在させ
てはいけません</em>。それは、はちゃめちゃへの一本道です。
<prgn>dpkg</prgn> がパッケージをアップグレードする際に毎回
ファイルを上書きするかどうか問い合わせてくるようになり、頭を
掻きむしることになります。
</p>
</sect1>
<sect1>
<!-- <heading>Sharing configuration files</heading>-->
<heading>設定ファイルの共用</heading>
<p>
<!-- Only packages that are tagged <em>conflicting</em> with
each other may specify the same file as
<tt>conffile</tt>.-->
<em>conflict</em> していると宣言しているパッケージ間でのみ、同
じ名前のファイルを <tt>conffile</tt> として指定することができ
ます。</p>
<p>
<!-- The maintainer scripts should not alter the conffile of
<em>any</em> package, including the one the scripts belong
to.-->
メンテナスクリプトは、自分の属しているパッケージを含む<em>いか
なる</em>パッケージの conffile を変更してもいけません。</p>
<p>
<!-- If two or more packages use the same configuration file
and it is reasonable for both to be installed at the same
time, one of these packages must be defined as
<em>owner</em> of the configuration file, i.e. it will be
the package to list that distributes the file and lists it
as a <tt>conffile</tt>. Other packages that use the
configuration file should depend on the owning package if
they require the configuration file to operate. If the
other package will use the configuration file if present,
but is capable of operating without it, no dependency need
be declared.-->
もし二つ以上のパッケージが同じ設定ファイルを使用し、それらの
パッケージを同時にインストールしても問題がない場合には、これ
らのパッケージのうちの一つを設定ファイルの
<em>所有者(owner)</em> と定義してください。その設定ファイルを
同梱している旨列挙し、<tt>conffile</tt> と宣言するのはその所
有者となったパッケージです。ほかのその設定ファイルを使用する
パッケージは、動作時にその設定ファイルが必要ならば、所有者とな
ったパッケージに依存 (depend) させてください。もしほかのパッ
ケージはその設定ファイルがあれば使うけれども、そのファイルが
無くても動作はするということならば、依存関係の宣言は不要です。
</p>
<p>
<!-- If it is desirable for two or more related packages to
share a configuration file <em>and</em> for all of the
related packages to be able to modify that configuration
file, then the following should done:-->
もし二つ以上のパッケージが同じ設定ファイルを使用し、
<em>かつ</em> これらのパッケージが設定ファイルを変更する場
合がある、という状況下では、以下の各項を満たすようにしてく
ださい。
<enumlist>
<item>
<p>
<!-- have one of the related packages (the "core"
package) manage the configuration file with
maintainer scripts as described in the previous
section.-->
関連したパッケージの一つ ("core" パッケージと呼びます)
が前節で説明した方法で、メンテナスクリプトから設定
ファイルを管理するようにします。</p>
</item>
<item><p>
<!-- the core package should also provide a program that
the other packages may use to modify the
configuration file.-->
"core" パッケージは他のパッケージが設定ファイルを変更
する際に用いるプログラムを提供しなければいけません。</p>
</item>
<item>
<p>
<!-- the related packages must use the provided program
to make any modifications to the configuration file.
They should either depend on the core package to
guarantee that the configuration modifier program is
available or accept gracefully that they cannot
modify the configuration file if it is not.-->
関連するパッケージは設定ファイルを変更する際には上で
記した "core" パッケージの提供するプログラムを使わなけ
ればいけません。また、関連するパッケージは変更のための
プログラムが存在することを保証するために "core" パッケ
ージに依存することを宣言するか、変更のためのプログラム
がなかったときにはエラー等を出さず変更をあきらめるよう
にするかの、どちらかとしておかなければいけません。</p>
</item>
</enumlist></p>
<p>
<!-- Sometimes it's appropriate to create a new package which
provides the basic infrastructure for the other packages
and which manages the shared configuration files. (Check
out the <tt>sgml-base</tt> package as an example.)-->
場合によっては、他のパッケージの基本的な土台を作成し、共有の
設定ファイルを管理する新パッケージを作成した方がいいこともあ
ります (例として <tt>sgml-base</tt> パッケージを参考にしてく
ださい)。</p>
</sect1>
<sect1>
<!-- <heading>User configuration files ("dotfiles")</heading> -->
<heading>ユーザ設定ファイル (ドットファイル)</heading>
<p>
<!-- Files in <tt>/etc/skel</tt> will automatically be copied
into new user accounts by <prgn>adduser</prgn>. They
should not be referenced there by any program.-->
<tt>/etc/skel</tt> にあるファイルは <prgn>adduser</prgn> に
よって自動的に新ユーザのアカウント下にコピーされます。この
<tt>/etc/skel</tt> 以下は他のどのプログラムからも参照しては
いけません。</p>
<p>
<!-- Therefore, if a program needs a dotfile to exist in
advance in <tt>$HOME</tt> to work sensibly that dotfile
should be installed in <tt>/etc/skel</tt> (and listed in
conffiles, if it is not generated and modified dynamically
by the package's installation scripts).-->
この関係で、プログラムが動作するのに <tt>$HOME</tt> ディレ
クトリにドットファイルをあらかじめ用意しておく必要があるなら
ば、ドットファイルはあらかじめ <tt>/etc/skel</tt> にインスト
ールしておかなければいけません (また、パッケージインストール
スクリプト中で作成なり変更なりを行わないなら、conffile に列
挙しておかなければなりません)。</p>
<!-- はなしが変なんですが…。必要条件にしかならないし、事後処理
も不明 -->
<p>
<!-- However, programs that require dotfiles in order to
operate sensibly (dotfiles that they do not create
themselves automatically, that is) are a bad thing, and
programs should be configured by the Debian default
installation as close to normal as possible.-->
とは言っても、自分で自動的に作成するもの以外のドットファイル
が正しく動作するのに必要なプログラムというものは望ましいもの
ではありません。プログラムは Debian の標準インストール状態で
そこそこ真っ当に動くように設定されていなければいけません。</p>
<p>
<!-- Therefore, if a program in a Debian package needs to be
configured in some way in order to operate sensibly that
configuration should be done in a site-wide global
configuration file elsewhere in <tt>/etc</tt>. Only if the
program doesn't support a site-wide default configuration
and the package maintainer doesn't have time to add it
should a default per-user file be placed in
<tt>/etc/skel</tt>.-->
したがって、 Debian パッケージのプログラムを真っ当に動くよ
うにする設定が必要なら、<tt>/etc</tt> 内にサイト共通で利用
する設定ファイルを用意してください。プログラムがサイト共通
の標準設定ファイルをサポートしておらず、パッケージメンテナ
がその機能を追加する余裕がないときのみ、<tt>/etc/skel</tt>
にユーザ個別のファイルをおくようにしてください。</p>
<p>
<!-- <tt>/etc/skel</tt> should be as empty as we can make it.
This is particularly true because there is no easy
mechanism for ensuring that the appropriate dotfiles are
copied into the accounts of existing users when a package
is installed.-->
<tt>/etc/skel</tt> はできる限り空になるようにしましょう。パッ
ケージをインストールしたときに、ドットファイルを現存のユーザ
にコピーする簡単な仕組みがないことからも、そうすべきなのは明
らかだと思います。</p>
</sect1>
</sect>
<sect>
<!-- <heading>Log files</heading> -->
<heading>ログファイル</heading>
<p>
<!-- The traditional approach to log files has been to set up ad
hoc log rotation schemes using simple shell scripts and
cron. While this approach is highly customizable, it
requires quite a lot of sysadmin work. Even though the
original Debian system helped a little by automatically
installing a system which can be used as a template, this
was deemed not enough. -->
従来のログファイルの扱いは、単純なスクリプトと cron を使って
場当たり的にログを循環させるようにするものでした。このやり方
は望みに応じてどのような修正もできるという利点はあるものも、
システム管理者の作業が多量に必要になります。初期の Debian シ
ステムではテンプレートとして使うスクリプトを自動でインストー
ルするようにして多少の作業の手間の緩和をはかっていましたが、
十分とはいえませんでした。
</p>
<p>
<!-- A better scheme is to use logrotate, a GPL'd program
developed by Red Hat, which centralizes log management. It
has both a configuration file (<tt>/etc/logrotate.conf</tt>)
and a directory where packages can drop logrotation info
(<tt>/etc/logrotate.d</tt>). -->
もっといい方法は、Red Hat 社が作成して GPL としてリリースした
log を集中管理する <prog>logrotate</prog> プログラムを使う方
法です。このプログラムは設定ファイル (<tt>/etc/logrotate.conf
</tt>) と、パッケージがログを循環させるための設定を書き込むた
めのディレクトリ (<tt>/etc/logrotate.d</tt>) の両方を備えてい
ます。
</p>
<!-- 訳者権限で tag 追加 -->
<p>
<!-- Log files should usually be named
<tt>/var/log/<var>package</var>.log</tt>. If you have many
log files, or need a separate directory for permissions
reasons (<tt>/var/log</tt> is writable only by
<tt>root</tt>), you should usually create a directory named
<tt>/var/log/<var>package</var></tt>.-->
ログファイルは通常 <tt>/var/log/<var>package</var>.log</tt>
という名にします。たくさんの log ファイルを持つパッケージや、
読み書き権限の設定のために独立のディレクトリを必要とする場合に
は (<tt>/var/log</tt> は <tt>root</tt> ユーザからのみ書き込め
ます) 特に理由がなければ <tt>/var/log/<var>package</var></tt>
という名のディレクトリを作成して使ってください。</p>
<p>
<!-- Make sure that any log files are rotated occasionally so
that they don't grow indefinitely; the best way to do this
is to drop a script into the directory
<tt>/etc/logrotate.d</tt> and use the facilities provided by
logrotate. Here is a good example for a logrotate config
file (for more information see <manref name="logrotate"
section="8">): -->
ログファイルは時々循環させるようにして、どこまでも大きくなること
がないようにしてください。これを実現する最良の方法は、ディレク
トリ <tt>/etc/logrotate.d</tt> にスクリプトを置き、logrotate
の提供する機能を使うやり方です。以下に logrotate の設定ファイル
のいい例を挙げましょう (詳しくは <manref name="logrotate"
section="8"> を見てください)。
<example>
/var/log/foo/* {
rotate 12
weekly
compress
postrotate
/etc/init.d/foo force-reload
endscript
}
</example>
<!-- Which rotates all files under `/var/log/foo', saves 12
compressed generations, and sends a HUP signal at the end of
rotation. -->
上記の例は `/var/log/foo' 以下の全ファイルを巡回させ、12 世代
分保存し、循環終了時に HUP シグナルを送信するものです。
</p>
<p>
<!-- Make sure that any log files are removed when the package is
purged (but not when it is only removed), by checking the
argument to the <tt>postrm</tt> script (see the <em>Debian
Packaging Manual</em> for details).-->
パッケージが完全削除 (purge) された時には、ログファイルがすべ
て消去されるよう (パッケージが削除されたときには消しません)
<tt>postrm</tt> スクリプトに与えた引数を確認してください。</p>
</sect>
<sect>
<!-- <heading>Permissions and owners</heading> -->
<heading>ファイル属性と所有者</heading>
<p>
<!-- The rules in this section are guidelines for general use.
If necessary you may deviate from the details below.
However, if you do so you must make sure that what is done
is secure and you must try to be as consistent as possible
with the rest of the system. You should probably also
discuss it on <prgn>debian-devel</prgn> first.
-->
この節の以下で記載されているのは一般的なガイドラインですので
必要に応じて細部でここから離れてもかまいません。しかしながら
やっていることがセキュリティ上問題がないこと、またシステムの
ほかの部分との整合性を可能な限り維持していることを必ず確認し
てください。おそらくまず <prgn>debian-devel</prgn> で論議す
るのがいいでしょう。</p>
<p>
<!-- Files should be owned by <tt>root.root</tt>, and made
writable only by the owner and universally readable (and
executable, if appropriate).-->
ファイルは <tt>root.root</tt> の所有権で、所有者書き込み可能
で誰でも読める (および適宜実行可能である) ようにしてください。</p>
<p>
<!-- Directories should be mode 755 or (for group-writability)
mode 2775. The ownership of the directory should be
consistent with its mode--if a directory is mode 2775, it
should be owned by the group that needs write access to
it.-->
ディレクトリのパーミッションは 755、あるいは、グループが書
き込み可であれば 2775 にすべきです。ディレクトリの所有者は
パーミッションに合わせてください。つまりディレクトリのパー
ミッションが 2775 であれば、そこに書き込む必要のあるグルー
プを所有者に設定してください。</p>
<p>
<!-- Setuid and setgid executables should be mode 4755 or 2755
respectively, and owned by the appropriate user or group.
They should not be made unreadable (modes like 4711 or
2711 or even 4111); doing so achieves no extra security,
because anyone can find the binary in the freely available
Debian package--it is merely inconvenient. For the same
reason you should not restrict read or execute permissions
on non-set-id executables.-->
setuid や setgid された実行ファイルのパーミッションはそれぞ
れ 4755、2755 で、適切な所有者とグループに設定されねばなりま
せん。それらを読み込み不可 (4711 や 2711、4111 など) にして
はいけません。誰でも自由に利用可能な Debian パッケージのバイ
ナリを探してくることができるので、読み込み不可にすることはセ
キュリティ対策にはならず、単に不便にするだけです。同じ理由で
set-id していない実行ファイルに対して読み込み・実行許可を制
限すべきではありません。</p>
<p>
<!-- Some setuid programs need to be restricted to particular
sets of users, using file permissions. In this case they
should be owned by the uid to which they are set-id, and
by the group which should be allowed to execute them.
They should have mode 4754; there is no point in making
them unreadable to those users who must not be allowed to
execute them.-->
ある種の setuid を使うプログラムではファイルのパーミッションを
使って、実行をある特定のユーザのみに制限する必要があります。こ
の場合 set-id したいユーザの uid を所有者として、実行を許可され
たグループに実行許可を与えます。この時のパーミッションは 4754
です。実行を許さないユーザに対して読み込み不可にすることは、前
述の理由で意味がありません。</p>
<p>
<!-- Do not arrange that the system administrator can only
reconfigure the package to correspond to their local
security policy by changing the permissions on a binary.
Ordinary files installed by (as opposed
to conffiles and other similar objects) have their
permissions reset to the distributed permissions when the
package is reinstalled. Instead you should consider (for
example) creating a group for people allowed to use the
program(s) and making any setuid executables executable
only by that group.-->
システム管理者がローカルなセキュリティの方針に合わせるため、
各バイナリのパーミッションを変えてパッケージを再設定せざる
を得ないような枠組にしてはいけません。設定ファイルやその他
の同様な対象は、パッケージを <prgn>dpkg</prgn> を使って再
インストールしたときに配布時のパーミッションに戻ってしまい
ます。その代わりに、例えばプログラムを利用することができる
グループを作り、 setuid した実行ファイルはそのグループだけ
が実行できるような設定とすることを考えてください。</p>
<p>
<!-- If you need to create a new user or group for your package
there are two possibilities. Firstly, you may need to
make some files in the binary package be owned by this
user or group, or you may need to compile the user or
group id (rather than just the name) into the binary
(though this latter should be avoided if possible). In
this case you need a statically allocated id.-->
パッケージのために新しいユーザまたはグループを作成する必要が
ある場合、二つの方法があります。第一の方法は、このユーザまた
はグループを所有者としてバイナリパッケージの所定のファイルを
作成します。または、可能な限り避けるべきですが、バイナリに単
なる名前ではなくユーザあるいはグループ ID をコンパイル時に埋
め込むようにもできます。これらの方法を採る場合、静的に割り当
てられた ID が必要となります。</p>
<p>
<!-- You must ask for a user or group id from the base system
maintainer, and must not release the package until you
have been allocated one. Once you have been allocated one
you must make the package depend on a version of the base
system with the id present in <tt>/etc/passwd</tt> or
<tt>/etc/group</tt>, or alternatively arrange for your
package to create the user or group itself with the
correct id (using <tt>adduser</tt>) in its pre- or
post-installation script (the latter is to be preferred if
it is possible).-->
このやり方を取る場合、base システムの管理者にユーザあるいは
グループ ID の割り当てを求めます。割り当てられるまでパッケー
ジをリリースすることはできません。このようなユーザやグループ
が割り当てられたらならば、パッケージは当該 ID を
<tt>/etc/passwd</tt> ないしは <tt>/etc/group</tt> に含むよう
な base システムの特定以降のバージョンに依存するようにするか、
パッケージ中の pre- または postinst スクリプト等で割り当てら
れた ID を (<tt>adduser</tt> などを使って) 自分で作成するよ
うにしてください。postinst で行うほうが、可能ならばより良い
やり方です。</p>
<p>
<!-- On the other hand, the program may able to determine the
uid or gid from the group name at runtime, so that a
dynamic id can be used. In this case you must choose an
appropriate user or group name, discussing this on
<prgn>debian-devel</prgn> and checking with the base
system maintainer that it is unique and that they do not
wish you to use a statically allocated id instead. When
this has been checked you must arrange for your package to
create the user or group if necessary using
<prgn>adduser</prgn> in the pre- or post-installation
script (again, the latter is to be preferred if it is
possible).-->
第二の方法は、プログラムが実行時にグループ名から uid、gid を決
定するもので、ID は動的に割り当てられます。
<footnote>
訳注：ここでの動的、はインストール時ホスト毎に、の意。
</footnote>
この場合、適切なユーザ名あるいはグループ名を選ばなければいけ
ません。これには <prgn>debian-devel</prgn> で討議を行い、また
base システムの管理者にその名前が一意であること、静的に ID
を割り当てたほうが望ましいということがないか、の二点を問い合
わせます。これらの確認がすんだ後パッケージで pre- あるいは
postinst スクリプト等で (繰り返しますが後者が好ましいです)
必要に応じて <prgn>adduser</prgn> を使ってユーザあるいはグル
ープを作成するようにしてください。</p>
<p>
<!-- Note that changing the numeric value of an id associated with
a name is very difficult, and involves searching the file system
for all appropriate files. You need to think carefully whether a
static or dynamic id is required, since changing your mind later
will cause problems.-->
名前に関連した ID の値を変えることはとても難しく、全ての関連
したファイルをファイルシステムから検索する必要があることに注
意してください。後になってからの変更は問題を起こしますので、
ID は静的か動的か良く考えて決めてください。</p>
</sect>
</chapt>
---------- >8 ---------- >8
--
Seiji Kaneko skaneko@xxxxxxxxxxxx
--------------------------- http://plaza25.mbn.or.jp/~efialtes