[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
debian-policy-3.5.4.0rc6pre4
かねこです。
3.5.5.0 の追従にかなりかかりそうなので (diff とったら 9000 行オ
ーバ）、平行作業ということで 3.5.4.0 の現状の査読をお願いします。
よろしくお願いします。
＃Perl policy も出来てないんだよなぁ。
------>8------------>8------------>8------------>8------------>8
<!doctype debiandoc system [
<!-- include version information so we don't have to hard code it
within the document -->
<!-- 文書の中に直接書き込まなくても良いように、
ここでバージョン情報を挿入する。-->
<!--
<!entity % versiondata SYSTEM "version.ent"> %versiondata;
]>
-->
<!entity % versiondata SYSTEM "version.ja.ent"> %versiondata;
]>
<debiandoc>
<!--
Debian GNU/Linux Policy Manual.
Copyright (C)1996,1997,1998 Ian Jackson and Christian Schwarz;
released under the terms of the GNU
General Public License, version 2 or (at your option) any later.
Initial version 1996, Ian Jackson, ijackson@xxxxxxxxxxxxxx
Revised November 27, 1996, David A. Morris, bweaver@debian.org
New sections March 15, 1997, Christian Schwarz, schwarz@debian.org
Reworked/Restructured April-July 1997, Christian Schwarz, schwarz@debian.org
Maintainer since 1997, Christian Schwarz, schwarz@debian.org
Christoph Lameter contributed the "Web Standard"
The debian-policy mailing list has taken responsibility for the
contents of this document since September 1998, with the package
maintainers responsible for packaging administrivia only.
-->
<!--
Debian GNU/Linux ポリシーマニュアル。
Copyright (C) 1996,1997,1998 Ian Jackson and Christian Schwarz.
GNU 一般公有使用許諾書(GPL)バージョン 2 が規定する条件の下で配布。GPL に
関しては、バージョン 2 以降のものであればどれを採用しても構わない。
初版: 1996 Ian Jackson, ijackson@xxxxxxxxxxxxxx
改訂: 1996 年 11 月 27 日、David A. Morris, bweaver@debian.org
項を新たに追加: 1997 年 3 月 15 日、Christian Schwarz, schwarz@debian.org
1997 年以降の管理者: Christian Schwarz, schwarz@debian.org
Web に関する規範は Christoph Lameter の寄稿による。
1998 年 9 月以来、debian-policy メーリングリストがこの文書の内容について
責任を負っている。パッケージメンテナはパッケージ管理に関係する雑務にのみ
責任を負う。
-->
<!-- JAPANESE
日本語訳は八田真行 mhatta@debian.or.jp 、かねこ skaneko@xxxxxxxxxxxx、
森本 odin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx が行い、査読を debian-doc
メンバ debian-doc@debian.or.jp で行った。ライセンスは原文と
同一とする。日本語訳に特有の部分には文字列 JAPANESE を含むコメントを付した。
3.5.0.0 で追加された Packaging manual 由来の部分は、早瀬 茂規 <shayase@xxxxxxxxxxxxxxx>、芳尾 桂 <shishamo@xxxxxxxxxxxxxxx> 両名による。
-->
<book>
<titlepag>
<!--
<title>Debian Policy Manual</title>
-->
<title>Debian ポリシーマニュアル</title>
<author>
<name>Ian Jackson </name>
<email>ijackson@xxxxxxxxxxxxxx</email>
</author>
<author>
<name>Christian Schwarz</name>
<email>schwarz@debian.org</email>
</author>
<author>
<!--
<name>revised: David A. Morris</name>
-->
<name>改訂: David A. Morris</name>
<email>bweaver@debian.org</email>
</author>
<author>
<!--
<name>The Debian Policy mailing List</name>
-->
<name>Debian ポリシーメーリングリスト</name>
<email>debian-policy@lists.debian.org</email>
</author>
<author>
<name>翻訳 Debian-doc-jp メーリングリスト (八田、森本、かねこ、早瀬、芳尾)</name>
<email>debian-doc@debian.or.jp</email>
</author>
<!--
<version>version &version;, &date;</version>
-->
<version>バージョン &version;, &date;</version>
<abstract>
<!--
This manual describes the policy requirements for the Debian
GNU/Linux distribution. This includes the structure and
contents of the Debian archive and several design issues of the
operating system, as well as technical requirements that each
package must satisfy to be included in the distribution. The
policy package itself is maintained by a group of maintainers
that have no editorial powers. At the moment, the list of
maintainers is:
-->
このマニュアルでは、Debian GNU/Linux ディストリビューションのポリシー
(方針)、すなわち Debian
に要求されるいくつかの必要条件について説明します。
このポリシーには、Debian
アーカイブの構成と内容、オペレーティングシステムとしての
Debian の設計に関するいくつかの事項に加えて、それぞれのパッケージがディストリビューションに受け入れられるために満たさなければならない技術的な必要条件も含まれます。
Debian 用の policy パッケージは、ポリシー自体を編纂する権限は無い数人のメンテナによって管理されています。
現時点でのメンテナは次の通り:
<enumlist>
<item>
<p>Julian Gilbey <email>jdg@debian.org</email></p>
</item>
<item>
<p>Manoj Srivastava <email>srivasta@debian.org</email></p>
</item>
</enumlist>
</abstract>
<copyright>
<copyrightsummary>
Copyright ©1996,1997,1998 Ian Jackson
and Christian Schwarz.
</copyrightsummary>
<p>
<!--
This manual is free software; you may redistribute it and/or
modify it under the terms of the GNU General Public License
as published by the Free Software Foundation; either version
2, or (at your option) any later version.
-->
このマニュアルはフリーソフトウェアです。フリーソフトウェア財団発行の
GNU 一般公有使用許諾書(GPL)バージョン 2 が規定する条件の下での再配布および改変を許可します。
GPL に関しては、バージョン
2 以降のものであればどれを採用してもかまいません。
</p>
<p>
<!--
This is distributed in the hope that it will be useful, but
<em>without any warranty</em>; without even the implied
warranty of merchantability or fitness for a particular
purpose. See the GNU General Public License for more
details.
-->
この文書は有用であるという期待の下に配布されていますが、
<em>無保証です</em>。販売に、あるいは特定の目的に適するという保証は、明示されているか否かを問わず一切存在しません。
詳しくは GNU 一般公有使用許諾書をご覧下さい。
</p>
<p>
<!--
A copy of the GNU General Public License is available as
<tt>/usr/share/common-licenses/GPL</tt> in the Debian GNU/Linux
distribution or on the World Wide Web at
<url id="http://www.gnu.org/copyleft/gpl.html";
name="The GNU General Public Licence">. You can also
obtain it by writing to the Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
-->
GNU 一般公有使用許諾書のコピーは、Debian GNU/Linux
ディストリビューションでは <tt>/usr/share/common-licenses/GPL</tt>
として、World Wide Web 上では GNU Public License
<url id="http://www.gnu.org/copyleft/gpl.html"; name=
"The GNU General Public License">として
入手可能です。また、Free Software Foundation, Inc.,
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
に請求しても手に入ります。
</p>
</copyright>
</titlepag>
<toc detail="sect">
<chapt id="scope">
<!--
<heading>About this manual</heading>
-->
<heading>このマニュアルについて</heading>
<sect>
<!--
<heading>Scope</heading>
-->
<heading>扱う範囲</heading>
<p>
<!--
This manual describes the policy requirements for the Debian
GNU/Linux distribution. This includes the structure and
contents of the Debian archive and several design issues of the
operating system, as well as technical requirements that
each package must satisfy to be included in the
distribution.
-->
このマニュアルでは、Debian GNU/Linux
ディストリビューションのポリシー(方針)、すなわち
Debian に要求されるいくつかの必要条件について説明します。
このポリシーには、Debian アーカイブの構成と内容、オペレーティングシステムとしての
Debian の設計に関するいくつかの事項に加えて、それぞれのパッケージがディストリビューションに受け入れられるために満たさなければならない技術的な必要条件も含まれます。
</p>
<p>
<!--This manual also describes Debian policy as it relates to
creating Debian packages. It is not a tutorial on how to build
packages, nor is it exhaustive where it comes to describing
the behavior of the packaging system. Instead, this manual
attempts to define the interface to the package management
system that the developers have to be conversant with.-->
このマニュアルは Debian パッケージ作成に関連した形で Debian
ポリシーを記載していますが、これはパッケージ作成手順を記載した手引きではなく、パッケージングシステムの挙動の記載については網羅的なものでもありません。
このマニュアルは、このような手引きというよりは、開発者が精通しておく必要のあるパッケージ管理システムとのインターフェースを規定することをねらったものです
<footnote>
<p>
<!-- Informally, the criteria used for inclusion is that the
material meet one of the following requirements:-->
非公式には、ここに収録される内容の選択基準は、次のどちらかに属していることです。
<taglist>
<tag><!-- Standard interfaces -->標準インターフェース</tag>
<item>
<p>
<!-- The material presented represents an interface to
the packaging system that is mandated for use, and
is used by, a significant number of packages, and
therefore should not be changed without peer
review. Package maintainers can then rely on this
interfaces not changing, and the package
management software authors need to ensure
compatibility with these interface
definitions. (Control file and and changelog file
formats are examples.)-->
記載された内容はパッケージングシステムのインターフェースとして使うべきものであり、実際に多数のパッケージで使われており、従って綿密なレビューなしには変更するべきでないようなものである場合です。
そのような場合にはパッケージメンテナはインターフェースがころころ変わらないことを期待できますし、パッケージ管理ソフトウェアの作者はそのインターフェース定義への互換性を確認するだけですみます
(コントロールファイルや changelog ファイル形式がその一例です)。
</p>
</item>
<tag><!-- Chosen Convention-->選ばれた取り決め</tag>
<item>
<p>
<!-- If there are a number of technically viable choices
that can be made, but one needs to select one of
these options for inter-operability. The version
number format is one example.-->
いくつか技術的には取りうる選択肢があり、相互互換性のためそのうちの一つを選ばなければならない場合です。
バージョン番号の形式などがその例です。
</p>
</item>
</taglist>
<!-- Please note that these are not mutually exclusive;
selected conventions often become parts of standard
interfaces. -->
これらが相互に排他なものではないことに注意してください。選ばれた取り決めが標準インターフェースになることはしばしばあります。
</p>
</footnote>。
</p>
<p>
<!-- The footnotes present in this manual are
merely informative, and are not part of Debian policy itself.-->
このマニュアル中の脚注は単に説明のためのものであり、Debian
ポリシーの一部ではありません。
</p>
<p> <!--
In this manual, the words <em>must</em>, <em>should</em> and
<em>may</em>, and the adjectives <em>required</em>,
<em>recommended</em> and <em>optional</em>, are used to
distinguish the significance of the various guidelines in
this policy document. Packages that do not conform the the
guidelines denoted by <em>must</em> (or <em>required</em>)
will generally not be considered acceptable for the Debian
distribution. Non-conformance with guidelines denoted by
<em>should</em> (or <em>recommended</em>) will generally be
considered a bug, but will not necessarily render a package
unsuitable for distribution. Guidelines denoted by
<em>may</em> (or <em>optional</em>) are truly optional and
adherence is left to the maintainer's discretion.-->
このマニュアルでは <em>しなければならない</em>、
<em>すべきである</em>、<em>してもよい</em> という語、および
<em>必要な</em>、<em>推奨された</em>、<em>オプションとして</em>
という形容詞はこのポリシー文書中の様々なガイドラインの重要度を示すために使われています。
<em>しなければならない</em> とされた、または <em>必要な</em>
とされたガイドラインに従っていないパッケージは一般的に
Debian ディストリビューションに受け入れて配布することはできないと判断されます。
一方、<em>すべきである</em> または <em>推奨された</em> ガイドライン
への不適合は通常はバグと見なされますが、ディストリビューションと
して配布不適合とまではされません。<em>してもよい</em> または
<em>オプションとして</em>
となっているガイドラインは本当にオプションであり、ガイドラインに従うかどうかはメンテナの判断に任されています。
</p>
<p><!--
These classifications are roughly equivalent to the bug
severities <em>serious</em> (for <em>must</em> or
<em>required</em> directive violations), <em>minor</em>,
<em>normal</em> or <em>important</em>
(for <em>should</em> or <em>recommended</em> directive
violations) and <em>wishlist</em> (for <em>optional</em>
items). <footnote>
<p>Compare RFC 2119. Note, however, that these words are
used in a different way in this document.</p>
</footnote> -->
</p>
<p>この分類は大雑把に言って、バグ分類の <em>serious</em>
(<em>しなければならない</em> と <em>必要な</em> 及びその派生語)、
<em>minor</em>、<em>normal</em> と <em>important</em>
(<em>すべきである</em> または
<em>推奨された</em> とその派生語)、<em>wishlist</em>
(<em>オプションとして</em> の類)に相当しています
<footnote><p>
RFC 2119 参照。
但し、これらの単語は本文中で違ったやり方で使われています。
</p></footnote>。
</p>
<p>
<!--
This document assumes familiarity with these other two
manuals. Unfortunately, the <em>System Administrators'
Manual</em> does not exist yet.
-->
この文書は、読者が前掲の二つのマニュアルの内容に精通していることを想定して書かれています。
しかし、残念なことに
<em>システム管理者マニュアル</em> はまだ存在していません。
</p>
<p>
<!--
Much of the information presented in this manual will be
useful even when building a package which is to be
distributed in some other way or is intended for local use
only.
-->
このマニュアルに載っている情報の多くは、Debian
アーカイブへの収録以外の方法で配布する、
あるいはお手元で使うだけで配布はしないといったパッケージを作成する際にも役に立つでしょう。
</p>
</sect>
<sect>
<!--
<heading>New versions of this document</heading>
-->
<heading>この文書の新しい版</heading>
<p>
<!--
The current version of this document is always accessible
from the Debian FTP server <ftpsite>ftp.debian.org</ftpsite>
as
<ftppath>/debian/doc/package-developer/policy.txt.gz</ftppath>
(also available from the same directory are several other
formats: <tt>policy.html.tar.gz</tt>, <tt>policy.pdf.gz</tt>
and <tt>policy.ps.gz</tt>) or from the <url
id="http://www.debian.org/doc/debian-policy/"; name="Debian
Policy Manual"> webpage.</p>
-->
この文書の最新版は常に Debian の FTP サーバ
<ftpsite>ftp.debian.org</ftpsite> 上の
<ftppath>/debian/doc/package-developer/policy.txt.gz</ftppath>
(幾つかの他のフォーマットも同じディレクトリに用意されています:
具体的には、<tt>policy.html.tar.gz</tt>, <tt>policy.pdf.gz</tt>
と <tt>policy.ps.gz</tt> です)
あるいは Debian の WWW サーバ上の Debian ポリシーマニュアルページ
<url id="http://www.debian.org/doc/debian-policy/"; name=
"The Debian Policy Manual">
として入手できます。
</p>
<p>
<!--
In addition, this manual is distributed via the Debian package
<tt>debian-policy</tt>.
-->
加えて、このマニュアルは Debian パッケージ <tt>debian-policy</tt>
としても配布されています。
</p>
<p><!--
The <tt>debian-policy</tt> package also includes the file
<tt>upgrading-checklist.txt</tt> which indicates policy
changes between versions of this document.-->
<tt>debian-policy</tt> にはこのドキュメントのバージョン間の変更を記載した
<tt>upgrading-checklist.txt</tt> ファイルも含まれています。
</p>
</sect>
<sect>
<!--
<heading>Feedback</heading>
-->
<heading>フィードバック</heading>
<p>
<!--
As the Debian GNU/Linux system is continuously evolving this
manual does so too.
-->
Debian GNU/Linux システムは継続的に進化していますので、
このマニュアルも時と共に変更が加えられています。
</p>
<p>
<!--
While the authors of this document have tried hard to avoid
typos and other errors, these do still occur. If you discover
an error in this manual or if you want to give any
comments, suggestions, or criticisms please send an email to
the Debian Policy List,
<email>debian-policy@lists.debian.org</email>, or submit a
bug report against the <tt>debian-policy</tt> package.
-->
誤植その他のいかなる誤りも入れないよう、この文書の筆者たちは非常に努力しましたが、それでも間違いは生じます。
もしこの文書の内容に誤りを見つけたり、何らかの意見や提案、批評を私たちに伝えたいという場合には、Debian
ポリシーメーリングリスト
<email>debian-policy@lists.debian.org</email>
まで電子メールをお送り頂くか、<tt>debian-policy</tt> パッケージに対してバグ報告を出して頂けると幸いです。
</p>
<p>
この日本語訳に関するご意見ご感想は debian-doc メーリングリスト
<email>debian-doc@debian.or.jp</email> までお送り下さい。
<!-- debian-doc-jp パッケージを作成して、それに対する BTS をおこなえるようにすべき -->
</p>
</sect>
</chapt>
<chapt>
<!--
<heading>The Debian Archive</heading>
-->
<heading>Debian アーカイブ</heading>
<p>
<!--
The Debian GNU/Linux system is maintained and distributed as a
collection of <em>packages</em>. Since there are so many of
them (currently well over 6000), they are split into
<em>sections</em> and given <em>priorities</em> to simplify
the handling of them.
-->
Debian GNU/Linux システムは <em>パッケージ</em> の集合体として
管理、配布されています。Debian には非常に数多くの
(現在優に 6000 個以上の)
パッケージが含まれますので、取り扱いを簡略化するためパッケージは
<em>セクション</em> と <em>プライオリティ</em>
によって分類されています。
</p>
<p>
<!--
The effort of the Debian project is to build a free operating
system, but not every package we want to make accessible is
<em>free</em> in our sense (see the Debian Free Software
Guidelines, below), or may be imported/exported without
restrictions. Thus, the archive is split into the sections
<em>main</em>, <em>non-free</em>, <em>contrib</em>,
<em>non-US/main</em>, <em>non-US/non-free</em>, and
<em>non-US/contrib</em>. The sections are explained in detail
below.
-->
Debian プロジェクトはフリーなオペレーティングシステムの構築を目指して努力を重ねていますが、私たちが利用可能にしたいと思う全てのパッケージが私たちの定義に沿った
<em>フリー</em> (詳しくは下記記載の <ref id="DFSG"> をご覧下さい)
なものであるわけではなく、また制限なしに輸出入ができるものとも限りません。
そこで、Debian
アーカイブは更に <em>main</em>、<em>non-free</em>、
<em>contrib</em>、<em>non-US/main</em>、<em>non-US/non-free</em>
と <em>non-US/contrib</em> の各セクションに分割されています。
これらのセクションについては以下で詳しく説明します。
</p>
<p>
<!--
The <em>main</em> and the <em>non-US/main</em> sections
together form the <em>Debian GNU/Linux distribution</em>.
-->
<em>Debian GNU/Linux ディストリビューション</em> とは <em>main</em>
と <em>non-US/main</em> の二つのセクションをあわせたものです。
</p>
<p>
<!--
Packages in the other sections are not considered to be part
of the Debian distribution, although we support their use and
provide infrastructure for them (such as our bug-tracking
system and mailing lists). This Debian Policy Manual applies
to these packages as well.
-->
この二つ以外のセクションに収録されているパッケージは Debian
ディストリビューションの一部とは見なされません。
しかしながら私たちはそれらのパッケージの使用を支援しますし、
またそれらに対するインフラストラクチャー
(バグ追跡システムやメーリングリストなど) を提供します。
Debian ポリシーマニュアルの記述はこれらのパッケージにも適用されます。
</p>
<sect id="pkgcopyright">
<!--
<heading>Package copyright and sections</heading>
-->
<heading>パッケージの著作権とセクション</heading>
<p>
<!--
The aims of this section are:
-->
この節の意図は次のようなものです。
<list compact="compact">
<item>
<p>
<!--
to allow us to make as much software available as we
can,
-->
可能な限り多くのソフトウェアを利用可能にしたい。
</p>
</item>
<item>
<p>
<!--
to allow us to encourage everyone to write free software, and
-->
すべての人に、フリーソフトウェアを書くことを奨励したい。
</p>
</item>
<item>
<p>
<!--
to allow us to make it easy for people to produce
CD-ROMs of our system without violating any licenses,
import/export restrictions, or any other laws.
-->
そして人々が私たちのシステムの CD-ROM を、いかなるライセンス、
輸出入制限、その他の法にも違反することなく簡単に制作できるようにしたい。
</p>
</item>
</list>
</p>
<sect1 id="DFSG">
<!--
<heading>The Debian Free Software Guidelines</heading>
-->
<heading>Debian フリーソフトウェアガイドライン</heading>
<p>
<!--
The Debian Free Software Guidelines (DFSG) form our
definition of `free' software.
-->
Debian フリーソフトウェアガイドライン (DFSG) は私たちが
「フリー」であると考えるソフトウェアの定義です。
<taglist>
<!--
<tag>Free Redistribution</tag>
-->
<tag>自由な再配布</tag>
<item>
<p>
<!--
The license of a Debian component may not restrict any
party from selling or giving away the software as a
component of an aggregate software distribution
containing programs from several different
sources. The license may not require a royalty or
other fee for such sale.
-->
Debian を構成する個々の部分要素 (パッケージなど)
のライセンスでは、その部分要素をいくつかの異なる出自を持つプログラムを複数含む集積されたソフトウェアの配布物の一部として販売ないし無料で配布することを、いかなる個人または団体に対しても制限してはなりません。
</p>
</item>
<!--
<tag>Source Code</tag>
-->
<tag>ソースコード</tag>
<item>
<p>
<!--
The program must include source code, and must allow
distribution in source code as well as compiled form.
-->
プログラムはソースコードを含んでいなければならず、コンパイル済み形式の配布だけでなくソースコードの配布も許可しなければなりません。
</p>
</item>
<!--
<tag>Derived Works</tag>
-->
<tag>派生物作成の許諾</tag>
<item>
<p>
<!--
The license must allow modifications and derived
works, and must allow them to be distributed under the
same terms as the license of the original software.
-->
ライセンスはソフトウェアの変更、およびその派生物の作成を許可しなければなりません。
また、それらがオリジナルのソフトウェアのライセンスと同じ配布条件の元で配布されることを許可しなければなりません。
</p>
</item>
<!--
<tag>Integrity of The Author's Source Code</tag>
-->
<tag>作者のソースコードへの変更の制限と配布条件</tag>
<item>
<p>
<!--
The license may restrict source-code from being
distributed in modified form <em>only</em> if the
license allows the distribution of ``patch files''
with the source code for the purpose of modifying the
program at build time. The license must explicitly
permit distribution of software built from modified
source code. The license may require derived works to
carry a different name or version number from the
original software. (This is a compromise. The Debian
Project encourages all authors to not restrict any
files, source or binary, from being modified.)
-->
プログラムをビルドする際にソースコードを変更するための
「パッチファイル」を、そのライセンスがソースコードと共に配布することを許可している場合に
<em>限り</em>、ライセンスは変更されたソースコードの配布を制限することができます。
この場合、ライセンスは変更されたソースコードからビルドされたソフトウェアの配布を明示的に許可していなければなりません。
ライセンスが派生物に対して、オリジナルのソフトウェアとは異なった名前ないしバージョン番号を冠することを要求することは認められます
(これは妥協です。Debian
プロジェクトではすべての作者にソース、バイナリを問わずいかなるファイルへの変更をも制限しないことを推奨しています)。
</p>
</item>
<!--
<tag>No Discrimination Against Persons or Groups</tag>
-->
<tag>個人ないし団体に対する排斥の禁止</tag>
<item>
<p>
<!--
The license must not discriminate against any person
or group of persons.
-->
ライセンスはいかなる個人ないし個人からなる団体に対しても差別をしてはなりません。
</p>
</item>
<!--
<tag>No Discrimination Against Fields of Endeavor</tag>
-->
<tag>使用分野に対する排斥の禁止</tag>
<item>
<p>
<!--
The license must not restrict anyone from making use
of the program in a specific field of endeavor. For
example, it may not restrict the program from being
used in a business, or from being used for genetic
research.
-->
ライセンスは誰に対しても、プログラムをある特定の分野で使用することを制限してはなりません。
例えば、ライセンスでプログラムを商用で使用すること、または遺伝子研究に使うことを制限してはなりません。
</p>
</item>
<!--
<tag>Distribution of License</tag>
-->
<tag>ライセンスの配布時の均一性</tag>
<item>
<p>
<!--
The rights attached to the program must apply to all
to whom the program is redistributed without the need
for execution of an additional license by those
parties.
-->
プログラムに付属する諸権利は、そのプログラムが再配布されるすべての人びとに、その人びとによるライセンスの追加条項の履行を必要とせずに適用されなければなりません。
</p>
</item>
<!--
<tag>License Must Not Be Specific to Debian</tag>
-->
<tag>ライセンスは Debian においてのみ適用されるものであってはならない
</tag>
<item>
<p>
<!--
The rights attached to the program must not depend on
the program's being part of a Debian system. If the
program is extracted from Debian and used or
distributed without Debian but otherwise within the
terms of the program's license, all parties to whom
the program is redistributed must have the same
rights as those that are granted in conjunction with
the Debian system.
-->
プログラムに付属する諸権利はそのプログラムがある Debian
システムの一部であるということに依存するものであってはなりません。
もしそのプログラムが Debian から取り出され、Debian
抜きで使用ないし配布されるとしても、そのプログラムのライセンスが定める条件の範囲内で扱われる限り、そのプログラムが再配布された全ての人びとは、Debian
システムとの関連に基づいて認められていたのと同じ諸権利を有さなければなりません。
</p>
</item>
<!--
<tag>License Must Not Contaminate Other Software</tag>
-->
<tag>ライセンスは他のソフトウェアに影響を及ぼしてはならない</tag>
<item>
<p>
<!--
The license must not place restrictions on other
software that is distributed along with the licensed
software. For example, the license must not insist
that all other programs distributed on the same medium
must be free software.
-->
ライセンスはそのライセンスが適用されたソフトウェアと一緒に配布される他のソフトウェアに制限を設けてはなりません。
例えば、ライセンスは同じメディアで配布される他のプログラム全てがフリーソフトウェアであることを主張してはなりません。
</p>
</item>
<!--
<tag>Example Licenses</tag>
-->
<tag>ライセンスの例</tag>
<item>
<p>
<!--
The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are
examples of licenses that we consider <em>free</em>.
-->
「GPL」、「BSD」、「Artistic」ライセンスなどが
私たちが <em>フリー</em> であると見なすライセンスの例です。
</p>
</item>
</taglist>
</p>
</sect1>
<sect1>
<!--
<heading>The main section</heading>
-->
<heading>main セクション</heading>
<p>
<!--
Every package in <em>main</em> and <em>non-US/main</em>
must comply with the DFSG (Debian Free Software
Guidelines).</p>
-->
<em>main</em> および <em>non-US/main</em>
に収録されるパッケージは全て DFSG (Debian
フリーソフトウェアガイドライン) に準拠していなければなりません。
</p>
<p>
<!--
In addition, the packages in <em>main</em>
-->
加えて、<em>main</em> に収録されるパッケージは
<list compact="compact">
<item>
<p>
<!--
must not require a package outside of <em>main</em> for
compilation or execution (thus, the package must not
declare a "Depends" , "Recommends", or
+ "Build-Depends" relationship on a
non-<em>main</em> package),
-->
コンパイルおよび実行に <em>main</em>
の範囲外のパッケージを必要としてはなりません
(即ち、パッケージは <em>main</em>
以外に収録されたパッケージに「依存」や「推奨」や
「ビルド時依存」関係を宣言してはなりません)。</p>
</item>
<item>
<p>
<!--
must not be so buggy that we refuse to support them,
and
-->
あまりにバグだらけで私たちがサポートすることを拒否するようなものであってはいけません。
</p>
</item>
<item>
<p>
<!--
must meet all policy requirements presented in this
manual.
-->
このマニュアルで示されている全てのポリシー要求に適合していなければいけません。
</p>
</item>
</list>
</p>
<p>
<!-- Similarly, the packages in <em>non-US/main</em>-->
同様に、<em>non-US/main</em> に収録されるパッケージは
<list compact="compact">
<item>
<p>
<!-- must not require a package outside of <em>main</em> or
<em>non-US/main</em> for compilation or execution,-->
コンパイルおよび実行に <em>main</em> または
<em>non-US/main</em>
の範囲外のパッケージを必要としてはなりません。
</p>
</item>
<item>
<p>
<!--
must not be so buggy that we refuse to support them,
-->
あまりにバグだらけで私たちがサポートすることを拒否するようなものであってはいけません。
</p>
</item>
<item>
<p>
<!--
must meet all policy requirements presented in this
manual.
-->
このマニュアルで示されている全てのポリシー要求に適合していなければいけません。
</p>
</item>
</list>
</p>
</sect1>
<sect1>
<!--
<heading>The contrib section</heading>
-->
<heading>contrib セクション</heading>
<p>
<!--
Every package in <em>contrib</em> and <em>non-US/contrib</em> must comply with the DFSG.
-->
<em>contrib</em> および <em>non-US/contrib</em> に収録される全てのパッケージは DFSG に準拠していなければなりません。
</p>
<p><!--
In addition, the packages in <em>contrib</em> and
<em>non-US/contrib</em>-->
これに加えて、<em>contrib</em> と <em>non-US/contrib</em>
のパッケージは
<list compact="compact">
<item>
<p><!--
must not be so buggy that we refuse to support them,
and -->
あまりにバグだらけで私たちがサポートすることを拒否するようなものであってはいけません。
</p>
</item>
<item>
<p><!--
must meet all policy requirements presented in this
manual.-->
このマニュアルで示されている全てのポリシー要求に適合していなければいけません。
</p>
</item>
</list>
</p>
<p><!--
Furthermore, packages in <em>contrib</em> must not require
a package in a <em>non-US</em> section for compilation or
execution.-->
更に、<em>contrib</em> のパッケージはコンパイルおよび実行に
<em>non-US</em> セクションのパッケージを必要としてはなりません。
</p>
<p>
<!--
Examples of packages which would be included in <em>contrib</em>
or <em>non-US/contrib</em> are
-->
<em>contrib</em> または <em>non-US/contrib</em>
に含められるようなパッケージの例としては
<list compact="compact">
<item>
<p>
<!--
free packages which require <em>contrib</em>,
<em>non-free</em> packages or packages which are not
in our archive at all for compilation or execution,
and
-->
<em>contrib</em> または<em>non-free</em> に属するパッケージ、
またはそもそも私たちのアーカイブに存在しないパッケージを、コンパイル時または実行時に必要とするフリーなパッケージ。
</p>
</item>
<item>
<p>
<!--
wrapper packages or other sorts of free accessories for
non-free programs.
-->
非フリーなプログラム用のラッパーパッケージ、あるいは非フリーなプログラム向けのフリーな付属物など。
</p>
</item>
</list>
</p>
</sect1>
<sect1>
<!--
<heading>The non-free section</heading>
-->
<heading>non-free セクション</heading>
<p>
<!--
Packages must be placed in <em>non-free</em> or
<em>non-US/non-free</em> if they are not compliant with
the DFSG or are encumbered by patents or other legal
issues that make their distribution problematic.
-->
DFSG に準拠していないパッケージ、または特許やその他の法的問題のために配布に問題のあるパッケージは
<em>non-free</em> または <em>non-US/non-free</em>
に収録しなければいけません。
</p>
<p><!--
In addition, the packages in <em>non-free</em> and
<em>non-US/non-free</em>-->
これに加えて、<em>non-free</em> と <em>non-US/non-free</em>
のパッケージは
<list compact="compact">
<item>
<p><!--
must not be so buggy that we refuse to support them,
and-->
あまりにバグだらけで私たちがサポートすることを拒否するようなものであってはいけません。
</p>
</item>
<item>
<p><!--
must meet all policy requirements presented in this
manual that it is possible for them to meet.-->
このマニュアルで示されている全てのポリシー要求に可能な限り適合していなければいけません。
<footnote>
<p><!--
It is possible that there are policy
requirements which the package is unable to
meet, for example, if the source is
unavailable. These situations will need to be
handled on a case-by-case basis.-->
パッケージが満たすことのできない要求、例えばソースが用意できない、などがあることは構いません。
これらの状況は個々に処置する必要があります。
</p>
</footnote>
</p>
</item>
</list>
</p>
</sect1>
<sect1>
<heading><!--The non-US sections-->non-US セクション</heading>
<p><!--
Some programs with cryptographic program code need to be
stored on the <em>non-US</em> server because of United
States export restrictions. Such programs must be
distributed in the appropriate <em>non-US</em> section,
either <em>non-US/main</em>, <em>non-US/contrib</em> or
<em>non-US/non-free</em>.-->
暗号に関わるプログラムコードを含むいくつかのプログラムは
「non-US」サーバに置く必要があります。
アメリカ合衆国がそのようなプログラムに対して輸出制限を加えているからです。
そのようなプログラムは
<em>non-US/main</em>、<em>non-US/contrib</em> または
<em>non-US/non-free</em> から適切に選ばれた
non-US セクションから配布しなければいけません。</p>
<p>
<!-- This applies only to packages which contain cryptographic
code. A package containing a program with an interface to
a cryptographic program or a program that's dynamically
linked against a cryptographic library should not be
distributed via the <em>non-US</em> server if it is
capable of running without the cryptographic library or
program.-->
この制限は、暗号化関連コードを含むパッケージのみに適用されます。
暗号化プログラム用のインターフェースを持つ含むパッケージ、
あるいは暗号に関わるライブラリに対して動的にリンクされているプログラムは、それが暗号ライブラリやプログラム無しで実行できるものであるならば、
<em>non-US</em> サーバではなく、通常のサーバから配布すべきです。
</p>
</sect1>
<sect1>
<!--
<heading>Further copyright considerations</heading>
-->
<heading>より突っ込んだ著作権に関する考察</heading>
<p>
<!--
Every package must be accompanied by a verbatim copy of
its copyright and distribution license in the file
<tt>/usr/share/doc/<em><package-name></em>/copyright</tt>
(see <ref id="copyrightfile"> for further details).
-->
全てのパッケージは、その著作権や配布ライセンスの無修正のコピーを
<tt>/usr/share/doc/<em><package-name></em>/copyright</tt>
ファイルとして同封して配布されなければなりません
(詳細は <ref id="copyrightfile"> を参照ください)。
</p>
<p>
<!--
We reserve the right to restrict files from being included
anywhere in our archives if
-->
私たちは、下記のような場合に当該ファイルを私たちのアーカイブのどこかへ収録することを制限する権利を留保します。
<list compact="compact">
<item>
<p>
<!--
their use or distribution would break a law,
-->
その使用ないし配布が何らかの法に抵触する。
</p>
</item>
<item>
<p>
<!--
there is an ethical conflict in their distribution or
use,
-->
その配布や使用に道徳的な見解の相違がある。
</p>
</item>
<item>
<p>
<!--
we would have to sign a license for them, or
-->
私たちがライセンスに署名する必要がある。
</p>
</item>
<item>
<p>
<!--
their distribution would conflict with other project
policies.
-->
その配布がプロジェクトの他の方針と矛盾する。
</p>
</item>
</list>
</p>
<p>
<!--
Programs whose authors encourage the user to make
donations are fine for the main distribution, provided
that the authors do not claim that not donating is
immoral, unethical, illegal or something similar; in such
a case they must go in <em>non-free</em>.
-->
ユーザに対して、作者への寄付を奨励しているプログラムを
<em>main</em> で配布することは、その作者が寄付をしないことを非道徳的であるとか、非倫理的であるとか、違法であるとか何かそれに類する主張をしていない限りなんら問題ありません。
そうでなければそのプログラムは
<em>non-free</em> に分類しなければいけません。
</p>
<p>
<!--
Packages whose copyright permission notices (or patent
problems) do not even allow redistribution of binaries
only, and where no special permission has been obtained,
must not be placed on the Debian FTP site and its mirrors
at all.</p>
-->
その著作権認可表示が (あるいは特許問題によって)
バイナリのみの再配布すら認めておらず、また特別な許可も得られていないプログラムのパッケージは、
Debian の FTP サイトにもそのミラーにも置いてはいけません。
</p>
<p>
<!--
Note that under international copyright law (this applies
in the United States, too), <em>no</em> distribution or
modification of a work is allowed without an explicit
notice saying so. Therefore a program without a copyright
notice <em>is</em> copyrighted and you may not do anything
to it without risking being sued! Likewise if a program
has a copyright notice but no statement saying what is
permitted then nothing is permitted.
-->
国際著作権法 (これはアメリカ合衆国でも適用されます) の下では、
明確にそう示されていない限り、ある作品の配布や変更は
<em>認められていない</em> ことに注意してください。
著作権表記が明記されていないプログラムにも著作権は
<em>存在する</em> のであり、そのようなプログラムに何らかの形で
手を加えるということは、いつ訴えられてもおかしくないということです!
同様に、著作権は明記されているが何が許可されているか述べられていないプログラムでは、なにも許可されていないということに他なりません。
</p>
<p>
<!--
Many authors are unaware of the problems that restrictive
copyrights (or lack of copyright notices) can cause for the
users of their supposedly-free software. It is often
worthwhile contacting such authors diplomatically to ask
them to modify their license terms. However, this can be a
politically difficult thing to do and you should ask for
advice on the <tt>debian-legal</tt> mailing list first, as
explained below.
-->
多くの作者は、制限のきつい著作権 (あるいは著作権表示の欠如)
が彼らの、意図としてはフリーなはずだったソフトウェアのユーザにもたらす数々の問題について気がついていません。
そこで、そのような作者たちと連絡をとって丁重に交渉し、彼らのライセンス条項を変更してもらうよう頼むのは多くの場合やってみる価値があることです。
しかし、これは政治上難しいことの一つであり、まずは
以下記載のように <tt>debian-legal</tt> で助言を求めるべきでしょう。
</p>
<p>
<!--
When in doubt, send mail to
<email>debian-legal@lists.debian.org</email>. Be prepared
to provide us with the copyright statement. Software
covered by the GPL, public domain software and BSD-like
copyrights are safe; be wary of the phrases `commercial use
prohibited' and `distribution restricted'.
-->
もし何かよく分からない点があれば、
<email>debian-legal@lists.debian.org</email> にメールを出しましょう。
私たちに問題の著作権表示を提供できるよう準備しておいてください。
GPL で保護されたソフトウェア、パブリックドメインソフトウェア、そして
BSD スタイルの著作権は問題ありません。
「商用利用は禁止」あるいは「配布に制限あり」といった言い回しに注意してください。
</p>
</sect1>
<sect1>
<!--
<heading>Subsections</heading>
-->
<heading>サブセクション</heading>
<p>
<!--
The packages in the sections <em>main</em>,
<em>contrib</em> and <em>non-free</em> are grouped further
into <em>subsections</em> to simplify handling.
-->
取り扱いを簡略化するため、<em>main</em>、<em>contrib</em>、
<em>non-US/main</em>、<em>non-free</em>、<em>non-US/contrib</em>、
<em>non-US/non-free</em>
の各セクションに含まれる全てのパッケージは更に
<em>サブセクション</em> に分類されます。
</p>
<p><!--
The section and subsection for each package should be
specified in the package's <tt>Section</tt> control
record. However, the maintainer of the Debian archive
may override this selection to ensure the consistency of
the Debian distribution. The <tt>Section</tt> field
should be of the form:-->
それぞれのパッケージのセクションとサブセクションはパッケージの
<tt>Section</tt> <em>コントロールファイル</em>
(control record) で指定すべきです。但し、
Debian ディストリビューションとしての一貫性を保証するため Debian
アーカイブの管理者がこの選択を上書きすることがあるかもしれません。
<tt>Section</tt> フィールドは以下の形式をとります：
<list compact="compact">
<item>
<p><!--
<em>subsection</em> if the package is in the
<em>main</em> section,-->
<em>subsection</em> これはパッケージが <em>main</em>
セクションに属する場合です。
</p>
</item>
<item>
<p><!--
<em>section/subsection</em> if the package is in
the <em>contrib</em> or <em>non-free</em> section,
and-->
<em>section/subsection</em> これはパッケージが
<em>contrib</em> または <em>non-free</em>
セクションに属する場合です。
</p>
</item>
<item>
<p><!--
<tt>non-US</tt>, <tt>non-US/contrib</tt> or
<tt>non-US/non-free</tt> if the package is in
<em>non-US/main</em>, <em>non-US/contrib</em> or
<em>non-US/non-free</em> respectively.-->
<tt>non-US</tt>, <tt>non-US/contrib</tt> または
<tt>non-US/non-free</tt>
これらはパッケージが順に <em>non-US/main</em>、
<em>non-US/contrib</em> 及び
<em>non-US/non-free</em> セクションに属する場合です。
</p>
</item>
</list>
</p>
<p>
<!--
The Debian archive maintainers provide the authoritative
list of subsections. At present, they are:-->
Debian アーカイブメンテナがサブセクションの公式リストを提供します。
現時点では、それらは下記の通りです。
<em>admin</em>, <em>base</em>, <em>comm</em>,
<em>contrib</em>, <em>devel</em>, <em>doc</em>,
<em>editors</em>, <em>electronics</em>, <em>games</em>,
<em>graphics</em>, <em>hamradio</em>,
<em>interpreters</em>, <em>libs</em>, <em>mail</em>,
<em>math</em>, <em>misc</em>, <em>net</em>, <em>news</em>,
<em>non-US</em>, <em>non-free</em>, <em>oldlibs</em>,
<em>otherosfs</em>, <em>science</em>, <em>shells</em>,
<em>sound</em>, <em>tex</em>, <em>text</em>,
<em>utils</em>, <em>web</em>, <em>x11</em>.
</p>
</sect1>
<sect>
<!--
<heading>Priorities</heading>
-->
<heading>プライオリティ</heading>
<p>
<!--
Each package should have a <em>priority</em> value, which is
included in the package's <em>control record</em>. This
information is used by the Debian package management tools
to separate high-priority packages from less-important
packages.</p>
-->
それそれのパッケージには所定の <em>priority</em> (優先度)
値が設定されているべきです。この値はパッケージの
<em>コントロールファイル</em>
に含まれています。この情報は Debian
のパッケージ管理ツールが優先度の高いパッケージを重要性の低いパッケージから選別する際に用いられます。
</p>
<p>
<!--
The following <em>priority levels</em> are recognised by the
Debian package management tools.
-->
Debian パッケージ管理システムが認識する <em>priority</em> の値
を下記に示します。
<taglist>
<tag><tt>required</tt></tag>
<item>
<p>
<!--
Packages which are necessary for the proper
functioning of the system. You must not remove these
packages or your system may become totally broken and
you may not even be able to use <prgn>dpkg</prgn> to
put things back. Systems with only the
<tt>required</tt> packages are probably unusable, but
they do have enough functionality to allow the
sysadmin to boot and install more software.
-->
システムが適切に機能するために必要なパッケージです。
これらのパッケージを削除してはなりません。
万一削除してしまうとシステムは完全に動作不能となり
<prgn>dpkg</prgn> で復旧することすら不可能になってしまいます。
<tt>required</tt> なパッケージのみのシステムはおそらく実用的ではないでしょうが、システム管理者がシステムを起動し、より多くのソフトウェアをインストールするに足るだけの機能は備えています。
</p>
</item>
<tag><tt>important</tt></tag>
<item>
<p>
<!--
Important programs, including those which one would
expect to find on any Unix-like system. If the
expectation is that an experienced Unix person who
found it missing would say `What on earth is going on,
where is <prgn>foo</prgn>?', it must be an
<tt>important</tt> package.
<footnote>
<p>
This is an important criterion because we are
trying to produce, amongst other things, a free
Unix.
</p>
</footnote>
Other packages without which the system will not run
well or be usable must also have priority
<tt>important</tt>. This does
<em>not</em> include Emacs, the X Window System, TeX
or any other large applications. The
<tt>important</tt> packages are just a bare minimum of
commonly-expected and necessary tools.</p>
-->
どんな Unix ライクなシステムに於いても見つかることが期待されるような重要なプログラムはこのプライオリティに属します。
そのプログラムが欠けていることに気づいた時、Unix
経験豊富なユーザが「<prgn>foo</prgn>
は一体全体どこだ?」と悪態をつくと思われるような場合には、それは
<tt>important</tt> に含まれるべき
<footnote>
<p>
私たちは何にもましてまずフリーな
Unix を創ろうとしているわけですから、これは重要な基準です。
</p>
</footnote>
です。それ無しではシステムが良好に動作しなかったり、
あるいは使い物にならないといった種類のパッケージもここに含められるべきです。
このカテゴリには Emacs、X ウィンドウシステム、TeX
といった大規模なアプリケーションは <em>含まれません</em>。
<tt>important</tt>
なパッケージには一般に存在が期待される、または必要といえるような、かつその最小の集合と考えられるツール類のみが含まれています。
</p>
</item>
<tag><tt>standard</tt></tag>
<item>
<p>
<!--
These packages provide a reasonably small but not too
limited character-mode system. This is what will
install by default if the user doesn't select anything
else. It doesn't include many large applications, but
it does include Emacs (this is more of a piece of
infrastructure than an application) and a reasonable
subset of TeX and LaTeX.
-->
これらのパッケージはほどよく小規模ながらもあまり制限のきつくない、キャラクタベースのシステムを提供します。
このパッケージ群がユーザが何も他に選択しなかった場合、デフォルトでインストールされます。大規模なアプリケーションの多くは含まれませんが、Emacs
(これは単なるアプリケーションという以上にインフラストラクチャーの一部なので)
と十分実用的な TeX および LaTeX のサブセットが含まれます。
</p>
</item>
<tag><tt>optional</tt></tag>
<item>
<p>
<!--
(In a sense everything that isn't required is
optional, but that's not what is meant here.) This is
all the software that you might reasonably want to
install if you didn't know what it was and don't have
specialized requirements. This is a much larger system
and includes the X Window System, a full TeX
distribution, and many applications. Note that
optional packages should not conflict with each other.
-->
(語の意味から言えば本来必要でないものはみんなオプション
なのですが、ここでは違った意味内容を示します。)
これは、そのパッケージが何か知らなくとも、また特殊な要求が無い場合にも、
とりあえずインストールしておく価値があると思われる全てのパッケージです。
これは X ウィンドウシステムや完全な TeX ディストリビューション、多くのアプリケーションを含み、ずっと大規模なシステムを構成します。
optional なパッケージは互いに conflict しないようにすべきです。
</p>
</item>
<tag><tt>extra</tt></tag>
<item>
<p>
<!--
This contains all packages that conflict with others
with required, important, standard or optional
priorities, or are only likely to be useful if you
already know what they are or have specialised
requirements.
-->
プライオリティとして required、important、standard、optional
のいずれかが指定されている他のパッケージと衝突するパッケージは全てこれに含まれます。
また、それが何なのかすでに知っている場合や、特段の要求事項がある場合にのみ有用であると考えられるパッケージ群もこのプライオリティに収録されます。
</p>
</item>
</taglist>
</p>
<p>
<!--
Packages must not depend on packages with lower priority
values (excluding build-time dependencies). In order to
ensure this, the priorities of one or more packages may need
to be adjusted.
-->
パッケージはそれよりも低いプライオリティ評価が与えられたパッケージに依存してはなりません
(ビルド時の依存は除きます)。
これを保証するため、一つまたは複数のパッケージのプライオリティを調整しなければならない場合があります。
</p>
</sect>
<sect>
<!--
<heading>Binary packages</heading>
-->
<heading>バイナリパッケージ</heading>
<p>
<!--
The Debian GNU/Linux distribution is based on the Debian
package management system, called <prgn>dpkg</prgn>. Thus,
all packages in the Debian distribution must be provided
in the <tt>.deb</tt> file format.
-->
Debian GNU/Linux ディストリビューションは <prgn>dpkg</prgn> と呼ばれる
Debian パッケージ管理システムに基礎を置いています。
このため、Debian ディストリビューションに含まれる全てのパッケージは
<tt>.deb</tt>ファイル形式で提供されなければなりません。
</p>
<sect1>
<!--
<heading>The package name</heading>
-->
<heading>パッケージ名</heading>
<p>
<!--
Every package must have a name that's unique within the Debian
archive.
-->
全てのパッケージは Debian アーカイブ内において重複しない名前を持っていなければなりません。
</p>
<p>
<!--
Package names must consist of lower case letters (a-z),
digits (0-9), plus (+) and minus (-) signs, and periods
(.). They must be at least two characters long and must
contain at least one letter.
-->
パッケージ名はアルファベット小文字、数字(0-9)、プラス(+)あるいは
マイナス(-)記号、ピリオド(.)でのみ構成されていなければなりません。
少なくとも二文字以上で、アルファベットを一文字以上含んでいなければいけません。
</p>
<p>
<!--
The package name is part of the file name of the
<tt>.deb</tt> file and is included in the control field
information.
-->
パッケージ名は <tt>.deb</tt> ファイルのファイル名の一部であり、
コントロールファイル中の制御フィールド情報に含まれます。
</p>
</sect1>
<sect1>
<!--
<heading>The maintainer of a package</heading>
-->
<heading>パッケージのメンテナ</heading>
<p>
<!--
Every package must have a Debian maintainer (the
maintainer may be one person or a group of people
reachable from a common email address, such as a mailing
list). The maintainer is responsible for ensuring that
the package is placed in the appropriate distributions.
-->
全てのパッケージには一時に一人の Debian メンテナ
(一人の個人であっても、共通の一つのメールアドレス
(たとえばメーリングリスト) で連絡の取れるグループであっても構いません) を持たなければなりません。
この人物は、そのパッケージが適切なディストリビューションに収録されていることに対する責任を持ちます。
</p>
<p>
<!--
The maintainer must be specified in the
<tt>Maintainer</tt> control field with their correct name
and a working email address. If one person maintains
several packages, he/she should try to avoid having
different forms of their name and email address in
the <tt>Maintainer</tt> fields of those packages.
-->
Debian パッケージのメンテナは各パッケージの <tt>Maintainer</tt>
制御フィールドに、正しい名前と有効な電子メールアドレスの両方により指定されていなければなりません。
もしその人がいくつかのパッケージを管理している場合、個々のパッケージの
<tt>Maintainer</tt> フィールドに異なった形式の名前と電子メールアドレスを記入することは避けるべきです。
</p>
<p>
<!--
If the maintainer of a package quits from the Debian
project, "Debian QA Group"
<email>packages@qa.debian.org</email> takes over the
maintainership of the package until someone else
volunteers for that task. These packages are called
<em>orphaned packages</em>.
-->
もしあるパッケージのメンテナが Debian プロジェクトを辞めたなら、
誰か他の人がその仕事に志願するまで Debian QA グループ
<email>packages@qa.debian.org</email>
がパッケージの管理を引き継ぎます。
このようなパッケージは <em>orphaned パッケージ</em>
と呼ばれます。
<!-- 別にプロジェクトをやめなくともメンテナは降りられるので、
この書き方は勇み足 -->
<footnote>
<p><!--
The detailed procedure for doing this gracefully can
be found in the Debian Developer's Reference, either
in the <tt>developers-reference</tt> package, or on
the Debian FTP server
<ftpsite>ftp.debian.org</ftpsite> as
<ftppath>/debian/doc/package-developer/developers-reference.txt.gz</ftppath>
or from the <url
id="http://www.debian.org/doc/packaging-manuals/developers-reference/";
name="Debian Developer's Reference"> webpage.-->
これを丁寧に行うやり方の詳細は Debian Developer's
Reference (開発者の手引き) に書かれています。この手引きは、
<tt>developers-reference</tt> パッケージ、または Debian FTP
サーバ <ftpsite>ftp.debian.org</ftpsite> の
<ftppath>/debian/doc/package-developer/developers-reference.txt.gz</ftppath>
そして <url id="http://www.debian.org/doc/packaging-manuals/developers-reference/";
name="Debian Developer's Reference">
ウェブページから入手できます。
</p>
</footnote>
</p>
</sect1>
<sect1>
<!--
<heading>The description of a package</heading>
-->
<heading>パッケージの説明</heading>
<p>
<!--
Every Debian package must have an extended description
stored in the appropriate field of the control record.
-->
全ての Debian パッケージには、コントロールファイル中の適切なフィールドに詳細な説明文が記入されていなければなりません。
</p>
<p>
<!--
The description should be written so that it gives the
system administrator enough information to decide whether
to install the package. This description should not just
be copied verbatim from the program's documentation.
Instructions for configuring or using the package should
not be included -- that is what installation scripts,
manual pages, info files, etc., are for. Copyright
statements and other administrivia should not be included
either -- that is what the copyright file is for.</p>
-->
説明文は、システム管理者がそのパッケージをインストールするかどうか決めるために知る必要があることを伝えられるように、書かれているべきです。
説明文はプログラムの説明文書をそのままコピーしただけのものとすべきではありません。
また、そのパッケージを設定したり使ったりするための解説を含めるべきではありません。
それはインストールスクリプト、マニュアルページ、Info
ファイルなどで扱われるべきです。
著作権表示やその他管理に関係する種々のことも含まれるべきではありません。
それら向けには copyright ファイルが用意されています。
</p>
</sect1>
<sect1>
<!--
<heading>Dependencies</heading>
-->
<heading>依存関係</heading>
<p>
<!--
Every package must specify the dependency information
about other packages that are required for the first to
work correctly.
-->
全てのパッケージには、それが正しく動作するためにまず必要となる他のパッケージについての依存情報が指定されていなければなりません。
</p>
<p>
<!--
For example, a dependency entry must be provided for any
shared libraries required by a dynamically-linked executable
binary in a package.
-->
例えば、パッケージに含まれている、動的にリンクされた実行形式バイナリが必要とする共有ライブラリは、依存関係のエントリで明示していなければなりません。
</p>
<p>
<!--
Packages are not required to declare any dependencies they
have on other packages which are marked <tt>Essential</tt>
(see below), and should not do so unless they depend
on a particular version of that package.
-->
但し、<tt>Essential</tt> (下記 <ref id="essential"> 参照)
と指定されているパッケージに対してそれ以外のパッケージが依存関係を宣言する必要はありません。
また、そのようなパッケージの特定のバージョンに依存しているのでなければ、依存関係を宣言すべきではありません。
<p>
<!--
Sometimes, a package requires another package to be
installed <em>and</em> configured before it can be
installed. In this case, you must specify a
<tt>Pre-Depends</tt> entry for the package.</p>
-->
時々、あるパッケージが、それをインストールする前にもう一つのパッケージがインストールされ
<em>かつ</em> 設定されていることを必要とすることがあります。
この場合、そのパッケージには
<tt>Pre-Depends</tt> エントリを指定しなければなりません。
<p>
<!--
You should not specify a <tt>Pre-Depends</tt> entry for a
package before this has been discussed on the
<tt>debian-devel</tt> mailing list and a consensus about
doing that has been reached.</p></sect1>
-->
<tt>debian-devel</tt>
メーリングリストで議論して同意が得られる前に、パッケージに
<tt>Pre-Depends</tt> エントリを指定するべきではありません。
</p>
<sect1 id="virtualpackage">
<!--
<heading>Virtual packages</heading>
-->
<heading>仮想パッケージ</heading>
<p>
<!--
Sometimes, there are several packages which offer
more-or-less the same functionality. In this case, it's
useful to define a <em>virtual package</em> whose name
describes that common functionality. (The virtual
packages only exist logically, not physically--that's why
they are called <em>virtual</em>.) The packages with this
particular function will then <em>provide</em> the virtual
package. Thus, any other package requiring that function
can simply depend on the virtual package without having to
specify all possible packages individually.
-->
多かれ少なかれ同じような仕事をこなすパッケージがいくつか存在するということがあります。
この場合、パッケージが持つ共通の機能を説明する名前の
<em>仮想パッケージ</em> を定義するのが便利です
(仮想パッケージは論理的に存在するだけで、物理的には存在しません。
これがそれらが <em>仮想</em> と呼ばれる理由です)。
特定の機能を持つこういったパッケージ群は皆仮想パッケージを
<em>提供</em> します。
そうしておけば、その機能を必要とする他のパッケージは単にその仮想パッケージに依存するようにすれば、可能性のある全てのパッケージをいちいち列挙しなくても良いわけです。
</p>
<p>
<!--
All packages should use virtual package names where
appropriate, and arrange to create new ones if necessary.
They must not use virtual package names (except privately,
amongst a cooperating group of packages) unless they have
been agreed upon and appear in the list of virtual package
names.
-->
全てのパッケージはそうするのが適当なときには仮想パッケージ名を使うべきで、もし必要ならば新しい仮想パッケージ名を作るようにしなければなりません。
但し、同意が得られ、仮想パッケージ名の一覧に掲載されるまで、新しい仮想パッケージ名を使うべきではありません
(非公式に、互いに関連する一群のパッケージの間で使う場合は除く)。
</p>
<p>
<!--
The latest version of the authoritative list of virtual
package names can be found on
<ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/virtual-package-names-list.txt</ftppath>
or your local mirror. In addition, it is included in the
<tt>debian-policy</tt> package. The procedure for updating
the list is described at the top of the file.
-->
正式な仮想パッケージ名の一覧の最新版は
<ftpsite>ftp.debian.org</ftpsite>の
<ftppath>/debian/doc/package-developer/virtual-package-names-list.txt</ftppath>
か、このサイトのお近くのミラーで見つかります。加えて、
この一覧は <tt>debian-policy</tt> パッケージにも含まれています。
このリストを更新するための手続きについてはこの一覧ファイルのはじめに記述されています。
</p>
</sect1>
<sect1>
<!--
<heading>Base packages</heading>
-->
<heading>Base パッケージ</heading>
<p>
<!--
The packages included in the <tt>base</tt> section have a
special function. They form a minimum subset of the Debian
GNU/Linux system that is installed before everything else
on a new system. Thus, only very few packages are allowed
to go into the <tt>base</tt> section to keep the required
disk usage very small.
-->
<tt>base</tt> セクションに含まれるパッケージは特別な機能を持っています。
それらは、新しいシステムに於いて他の全てに先だってインストールされる、
Debian GNU/Linux システムの最小のサブセットを形成します。
従って、必要となるディスク使用量を非常に小さく保つため、ほんの数パッケージのみが
<tt>base</tt> セクションへの収録を認められています。
</p>
<p>
<!--
Most of these packages will have the priority value
<tt>required</tt> or at least <tt>important</tt>, and many
of them will be tagged <tt>essential</tt> (see below).
-->
これらのパッケージのほとんどは、プライオリティ評価が
<tt>required</tt> であるか、少なくとも <tt>important</tt>
です。また、それらの大半には
<tt>essential</tt> 指定 (下記 <ref id="essential"> 参照) が付加されているでしょう。
</p>
<p>
<!--
You must not place any packages into the <tt>base</tt>
section before this has been discussed on the
<tt>debian-devel</tt> mailing list and a consensus about
doing that has been reached.
-->
<tt>debian-devel</tt>
メーリングリストで議論して同意が得られる前に、
パッケージを <tt>base</tt> セクションに収めてはいけません。
</p>
</sect1>
<sect1 id="essential">
<!--
<heading>Essential packages</heading>
-->
<heading>Essential パッケージ</heading>
<p>
<!--
Some packages are tagged <tt>essential</tt>. (They have
<tt>Essential: yes</tt> in their package control record.)
This flag is used for packages that are <em>essential</em>
for a system.
-->
いくつかのパッケージには <tt>Essential</tt> 指定が付加されています
(それらパッケージのコントロールファイル中で
<tt>Essential: yes</tt> という指定がされている)。
このフラグはシステムにとって <em>不可欠な</em>
パッケージに用いられます。
</p>
<p>
<!--
Since these packages cannot be easily removed (one has to
specify an extra <em>force option</em> to
<prgn>dpkg</prgn> to do so), this flag must not be used
unless absolutely necessary. A shared library package
must not be tagged <em>essential</em>--the dependencies will
prevent its premature removal, and we need to be able to
remove it when it has been superseded.
-->
これらのパッケージは簡単には削除できません (削除するには
<prgn>dpkg</prgn> に特別な <em>強制オプション</em>
を指定しなければならない)
ので、このフラグはどうしても必要な場合にのみ使うようにしなければなりません。
共有ライブラリのパッケージに <em>Essential</em> 指定をしてはいけません。
依存関係により誤った削除を阻止できますし、新しいものに入れ替える際には上書きできるようになっている必要があるからです。
</p>
<p><!--
Since dpkg will not prevent upgrading of other packages
while an <tt>essential</tt> package is in an unconfigured
state, all <tt>essential</tt> packages must supply all of
their core functionality even when unconfigured. If the
package cannot satisfy this requirement it must not be
tagged as essential, and any packages depending on this
package must instead have explicit dependency fields as
appropriate.-->
dpkg は <tt>Essential</tt> パッケージが未設定な状態でも他のパッケージのアップグレードを止めることはありませんので、
<tt>Essential</tt> パッケージはすべて、未設定状態でも基本機能はすべて提供している必要があります。
あるパッケージがこの条件を満たせない場合にはこのパッケージに
<tt>Essential</tt> 指定を行ってはいけませんし、そのパッケージに依存する他のパッケージは明示的に適切な依存関係フィールドを与えなければいけません。
</p>
<p>
<!--
You must not tag any packages <tt>essential</tt> before
this has been discussed on the <tt>debian-devel</tt>
mailing and a consensus about doing that has been
reached.
-->
<tt>debian-devel</tt> メーリングリストで議論して同意が得られない限り、パッケージに <tt>Essential</tt> 指定を付加してはなりません。
</p>
</sect1>
<sect1>
<!--
<heading>Maintainer scripts</heading>
-->
<heading>メンテナスクリプト</heading>
<p>
<!--
The package installation scripts should avoid producing
output which it is unnecessary for the user to see and
should rely on <prgn>dpkg</prgn> to stave off boredom on
the part of a user installing many packages. This means,
amongst other things, using the <tt>--quiet</tt> option on
<prgn>install-info</prgn>.
-->
パッケージのインストールスクリプトでは、ユーザにとって見る必要がない情報を出力することを避けるべきです。
また、大量のパッケージをインストールする際にユーザが退屈するのを避けるのも、<prgn>dpkg</prgn>
に任せておくべきです。
中でも、<prgn>install-info</prgn> を使うときは
<tt>--quiet</tt> オプションを使いましょう。
</p>
<p>
<!--
Errors which occur during the execution of an installation
script should be checked and the installation
should not continue after an error.
-->
インストールスクリプトの実行中に起こったエラーはチェックすべきですし、インストールはエラーの後実行を続けるべきではありません。
</p>
<p>
<!--
Note, that <ref id="scripts">, in general applies to
package maintainer scripts, too.
-->
全体として <ref id="scripts"> の内容はパッケージのメンテナスクリプトにも適用されます。
</p>
<p>
<!--
You should not use <prgn>dpkg-divert</prgn> on a file belonging to
another package without consulting the maintainer of that
package first.
-->
あるパッケージのメンテナと協議せずに、そのパッケージに属するファイルを置き換えるべく
<prgn>dpkg-divert</prgn> を使うべきではありません。
</p>
<p>
<!--
All packages which supply an instance of a common command
name (or, in general, filename) should generally use
<prgn>update-alternatives</prgn>, so that they may be
installed together. If <prgn>update-alternatives</prgn>
is not used, then each package must use <tt>Conflicts</tt>
to ensure that other packages are de-installed. (In this
case, it may be appropriate to specify a conflict against
earlier versions of something that previously did not use
<prgn>update-alternatives</prgn> - this is an exception to
the usual rule that versioned conflicts should be
avoided).
-->
「共通の」コマンド名 (あるいは、一般的にファイル名)
の具体的な実装を提供するすべてのパッケージは
<prgn>update-alternatives</prgn>
を使って同時に (複数の実装が) インストールできるようにすべきです。
(まだ) <prgn>update-alternatives</prgn>
を使っていない、このような共有コマンド名を提供する他のパッケージを強制的にインストール解除するためには
<tt>Conflicts</tt> を使わなければいけません。
(この場合に限って、以前の <prgn>update-alternatives</prgn>
を使っていなかったバージョンに対する Conflict
を指定してもかまいません。
これはこのようなヴァージョン競合の指定を許さない一般則への例外とします。)
</p>
<sect2>
<!-- <heading>Prompting in maintainer scripts</heading>-->
<heading>メンテナスクリプト中のプロンプト使用について</heading>
<p><!--
Package maintainer scripts may prompt the user if
necessary. Prompting may be accomplished by hand, or by
communicating with a program, such as
<prgn>debconf</prgn>, which conforms to the Debian
Configuration management specification, version 2 or
higher. These are included in the
<file>debconf_specification</file> files in the
<package>debian-policy</package> package.
You may also find this file on the FTP site
<ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/debconf_specification.txt.gz</ftppath>
or on your local mirror. -->
パッケージメンテナスクリプトは必要に応じてプロンプトを使ってユーザに入力を促すことができます。
プロンプト表示は自分で作成しても良く、Debian
設定管理仕様の第二版以降に準拠したプログラム
(例えば <prgn>debconf</prgn>) を介して行っても構いません
Debian 設定管理仕様の第二版は、<package>debian-policy</package>
パッケージの <file>debconf_specification</file>
ファイル中に含まれています。
また、FTP サイト <ftpsite>ftp.debian.org</ftpsite> の
<ftppath>/debian/doc/package-developer/debconf_specification.txt.gz</ftppath> にも置かれています
<footnote>
<p><!--
2.5% of Debian packages [see <url
id="http://kitenet.net/programs/debconf/stats/";>]
currently use <package>debconf</package> to prompt
the user at install time, and this number is growing
daily. The benefits of using debconf are briefly
explained at <url
id="http://kitenet.net/doc/debconf-doc/introduction.html";>;
they include preconfiguration, (mostly)
noninteractive installation, elimination of
redundant prompting, consistency of user interface,
etc.-->
現時点で 2.5 % の Debian パッケージがインストール時に debconf
を使っています [<url id="http://kitenet.net/programs/debconf/stats/";>]。
またその数は毎日増加しています。debconf を使う利点は
<url id="http://kitenet.net/doc/debconf-doc/introduction.html";>;
に簡単に説明されていますが、殆どの初期設定を含むこと、非対話的インストールが可能なこと、
不必要なプロンプトを避けられること、一貫したユーザインターフェースを実現できることなどがあげられましょう。
</p>
<p><!--
With this increasing number of packages using
<package>debconf</package>, plus the existance of a
nascent second implementation of the Debian
configuration management system
(<package>cdebconf</package>), and the stabalization
of the protocol these things use, the time has
finally come to reflect the use of these things in
policy.-->
<package>debconf</package> を使ったパッケージ数の増加と、Debian
設定管理システムの第二版 (<package>cdebconf</package>)
もまだ初期段階ですが出てきたこと、
そしてこれらが使っているプロトコルが安定してきたことから、
今回の時点でこれらの用法についてポリシーに取り込むことにしました。
</p>
</footnote>。
</p>
<p><!--
Packages which use the Debian Configuration management
specification may contain an additional
<file>config</file> script and a <file>templates</file>
file in their control archive. The <prgn>config</prgn>
script might be run before the <prgn>preinst</prgn>
script, and before the package is unpacked or any of its
dependancies or pre-dependancies are satisfied.
Therefore it must work using only the tools present in
<em>essential</em> packages.-->
Debian 設定管理仕様を用いるパッケージには制御アーカイブ中に追加で
<file>config</file> スクリプトと <file>templates</file>
ファイルを含めることができます。
<prgn>config</prgn> は、<prgn>preinst</prgn>
の前、かつパッケージがアンパックされる前、かつ
pre-dependency が満たされる前に走ることがありますので、
<em>Essential</em> パッケージに属するツールのみを
<footnote>
<p><!--
<package>Debconf</package> or another tool that
implements the Debian Configuration management
specification will also be installed, and any
versioned dependencies on it will be satisfied
before preconfiguration begins.-->
Debian 設定管理仕様を満たす <package>Debconf</package>
や他のツールは同様にインストールされていて、初期設定が始まるまでにそれらからのバージョン指定の依存関係がある場合、それが満たされている必要があります。
</p>
</footnote>
使う必要があります。
</p>
<p><!--
Packages should try to minimize the amount of prompting
they need to do, and they should ensure that the user
will only ever be asked each question once. This means
that packages should try to use appropriate shared
configuration files (such as <tt>/etc/papersize</tt> and
<tt>/etc/news/server</tt>), and shared
<package>debconf</package> variables rather than each
prompting for their own list of required pieces of
information.
-->
パッケージはそれらが必要とする質問の量を最小化するよう努力するべきです。
そして、それらはユーザがそれぞれの質問を一回だけ聞かれるようになっていることを確認しておくべきです。
噛み砕いて言うと、パッケージはそれ自身が必要とする一連の情報のために毎回質問するのではなく、
適切な共有の設定ファイル (例えば <tt>/etc/papersize</tt> や
<tt>/etc/news/server</tt> のような) や <package>debconf</package>
共有変数を使うように努力するべきであるということです。
</p>
<p>
<!--
It also means that an upgrade should not ask the same
questions again, unless the user has used <tt>dpkg
--purge</tt> to remove the package's configuration. The
answers to configuration questions should be stored in an
appropriate place in <tt>/etc</tt> so that the user can
modify them, and how this has been done should be
documented.</p>
-->
これはまた、アップグレードにおいて、ユーザがそのパッケージの設定をも削除するべく
<tt>dpkg --purge</tt> を使っていない限り、同じ質問を二度するべきではないということも意味します。
設定の質問の答えはユーザが変更できるよう
<tt>/etc</tt> 内の適切な場所に保存されていなければならず、またこれがどうされたかは文書化されているべきです。
<p>
<!--
If a package has a vitally important piece of
information to pass to the user (such as "don't run me
as I am, you must edit the following configuration files
first or you risk your system emitting badly-formatted
messages"), it should display this in the
<prgn>config</prgn> or <prgn>postinst</prgn> script and
prompt the user to hit return to acknowledge the
message. Copyright messages do not count as vitally
important (they belong in
<tt>/usr/share/doc/<var>package</var>/copyright</tt>);
neither do instructions on how to use a program (these
should be in on-line documentation, where all the users
can see them).
-->
もしそのパッケージがユーザに知らせなければならない非常に重要な情報を持っているとしたら
(例えば「このままで実行しないでください、下記の設定ファイルを最初に編集しないと、あなたのシステムがぐちゃぐちゃなメッセージを吐き出してしまう危険があります」)
その情報は <prgn>config</prgn> または <prgn>postinst</prgn> スクリプトにて表示し、ユーザにリターンキーを押して承認するよう質問するべきです。
著作権表示は極めて重要なものとは見なされません
(それらは
<tt>/usr/share/doc/<var>パッケージ名</var>/copyright</tt>
に収録してください)。
プログラムの使い方の説明もこの種の情報ではありません
(これらはオンライン文書として全てのユーザが読めるよう収録されるべきです)。
</p>
<p>
<!--
Any necessary prompting should almost always be confined
to the <prgn>config</prgn> or <prgn>postinst</prgn>
script. If it is done in the <prgn>postinst</prgn>, it
should be protected with a conditional so that unnecessary
prompting doesn't happen if a package's installation fails
and the <prgn>postinst</prgn> is called with
<tt>abort-upgrade</tt>, <tt>abort-remove</tt> or
<tt>abort-deconfigure</tt>.
-->
どんな必要な質問も、たいていの場合は <prgn>config</prgn> か
<prgn>postinst</prgn> スクリプトからに限られるべきです。
そして質問が <prgn>postinst</prgn> 中で行われていた場合、パッケージのインストールが失敗して
<prgn>postinst</prgn> が <tt>abort-upgrade</tt>、
<tt>abort-remove</tt>、あるいは <tt>abort-deconfigure</tt>
を引数として呼ばれたときには不必要な質問をしないよう、条件式によって必要以外の時に呼ばれないようにされているべきです。
</p>
</sect1>
</sect>
<sect>
<!--
<heading>Source packages</heading>
-->
<heading>ソースパッケージ</heading>
<sect1 id="standardsversion">
<!--
<heading>Standards conformance</heading>
-->
<heading>基準への準拠</heading>
<p>
<!--
In the source package's <tt>Standards-Version</tt> control
field, you must specify the most recent version number of
this policy document with which your package complies.
The current version number is &version;.
-->
ソースパッケージの <tt>Standards-Version</tt>
フィールドに、あなたのパッケージが準拠した最新のパッケージング基準のバージョンを指定しなければいけません。
現在のバージョン番号は &version; です。
</p>
<p><!--
This information may be used to file bug reports
automatically if your package becomes too much out of
date.-->
この情報は、あなたのパッケージがあまりにも旧式になってしまったときに自動的にバグレポートが提出されるのに使われます。
</p>
<p><!--
The version number has four components--major and
minor version number and major and minor patch level. When the
standards change in a way that requires every package to
change the major number will be changed. Significant
changes that will require work in many packages will be
signaled by a change to the minor number. The major patch
level will be changed for any change to the meaning of the
standards, however small; the minor patch level will be
changed when only cosmetic, typographical or other edits
are made which neither change the meaning of the document
nor affect the contents of packages.</p>
-->
バージョンナンバーはメジャー及びマイナーバージョン番号、さらにメジャー及びマイナーパッチレベルの 4 つの数字からなります。
全てのパッケージに渡って変更がなされる場合にはメジャーバージョンを変更します。
多くのパッケージに修正作業が必要な重要な変更の場合には、マイナーバージョンを変更することによってそれを示します。
パッチレベルについては、小さい変更であっても、それが基準の変更を伴う場合にはメジャーパッチレベルの変更となります。
マイナーパッチレベルの変更となるのは、表面上の変更、文書上の修正など意味合いの変化の無い場合、またパッケージの内容に関して影響を与えない場合になります。
</p>
<p><!--
Thus only the first three components of the policy version
are significant in the <em>Standards-Version</em> control
field, and so either these three components or the all
four components may be specified.
-->
従ってマニュアルバージョンのうち最初の
3 つの数字が一般的なバージョンとしての意味を持ちます。
この数字を 3 つにするか 4
つ全てを使ってバージョンを規定するかは、オプション
<footnote>
<p><!--
In the past, people specified the full version number
in the Standards-Version field, for example `2.3.0.0'.
Since minor patch-level changes don't introduce new
policy, it was thought it would be better to relax
policy and only require the first 3 components to be
specified, in this example `2.3.0'. All four
components may still be used if someone wishes to do
so.
-->
以前はバージョンを指定するのに、`2.3.0.0' という様に常に
全バージョン番号で表していましたが、最終桁のパッチレベルの変更は新しいポリシー内容を新規に導入するのではないため、
厳格なポリシーをゆるめて最初の
3 つの数字、この例では `2.3.0'、でバージョンを示すようにしたほうが、より良いだろうと思われるからです。
ただし、4 つ使いたければ使ってもかまいません。
</p>
</footnote> です。
</p>
<p>
<!-- You should regularly, and especially if your package has
become out of date, check for the newest Policy Manual
available and update your package, if necessary. When your
package complies with the new standards you should update the
<tt>Standards-Version</tt> source package field and
release it.
<footnote>
<p>
See the file <tt>upgrading-checklist</tt> for
information about policy which has changed between
different versions of this document.
</p>
</footnote>-->
常に最新のポリシーマニュアルをチェックしておきましょう。
あなたが過去にパッケージしたものがあって、それが古くなってしまっているなら特に必要です。
その上で必要があればパッケージのアップデートを行って下さい。
あなたのパッケージが新しい基準に則った際には、ソースパッケージの
<TT>Standards-Version</TT> を変更してリリースするべきです。
<footnote>
<p>
この文書の各版の間でポリシーにどのような変更が加えられたかについては
<tt>upgrading-checklist</tt> ファイルを参照ください。
</p>
</footnote>
</p>
</sect1>
<sect1>
<!-- <heading>Package relationships</heading> -->
<heading> パッケージ同士の依存関係</heading>
<p>
<!-- Source packages should specify which binary packages
they require to be installed or not to be installed in
order to build correctly. For example, if building a
package requires a certain compiler, then the compiler
should be specified as a build-time dependency. -->
ソースパッケージには、ビルドするためにインストールされていなければならない、またはインストールされていてはいけないようなバイナリパッケージが明記されているべきです。
例えば特定のコンパイラでないとビルドができない場合、ビルド時依存としてそのコンパイラが指定されているべきです。
</p>
<p>
<!-- It is not be necessary to explicitly specify
build-time relationships on a minimal set of packages that
are always needed to compile, link and put in a Debian
package a standard "Hello World!" program written in C or
C++. The required packages are called
<em>build-essential</em>, and an informational list can be
found in <tt>/usr/share/doc/build-essential/list</tt>
(which is contained in the <tt>build-essential</tt>
package). -->
しかしコンパイルに最小限必要なパッケージ (例えば C や C++
で書かれた "Hello World!" のようなプログラムをコンパイル、リンクし、
Debian パッケージ化するために必要なもの) までビルド時依存のものとして指定する必要はありません。
このような場合に必要となるパッケージは
<em>build-essential</em> と呼ばれ、<tt>build-essential</tt>
パッケージに収録されているファイル
<tt>/usr/share/doc/build-essential/list</tt>
<footnote>
<p>Rationale:
<list>
<item>
<p><!--This allows maintaining the list separately
from the policy documents (the list does not
need the kind of control that the policy
documents do).-->
これによって、このリストはポリシー関連文書とは別に管理されます (このリストはポリシー関連文書に必要な厳密な管理を行う必要はないので)。
</p>
</item>
<item>
<p><!--
Having a separate package allows one to install
the build-essential packages on a machine, as
well as allowing other packages such as task
packages to require installation of the
build-essential packages using the depends
relation.-->
独立パッケージにすることによってあるマシンに
build-essential なパッケージを依存関係によってインストールすることができますし、同時に他のパッケージ
(例えばタスクパッケージ) から build-essential
パッケージのインストールを同様に依存関係によって要求することができます。
</p>
</item>
<item>
<p><!--
The separate package allows bug reports against
the package to be categorized separately from
the policy management process that uses the BTS-->
また、これは独立したパッケージとしての管理を行っていますので、このパッケージのバグレポートの管理は
BTS を使ったポリシー管理プロセスとは分けて考える必要があります。
</p>
</item>
</list>
</p>
</footnote> にリストアップされています。
</p>
<p>
<!-- When specifying the set of build-time dependencies,
one should list only those packages explicitly required by
the build. It is not necessary to list packages which are
required merely because some other package in the list of
build-time dependencies depends on them.
<footnote>
<p>
The reason for this is that dependencies change, and
you should list all those packages, and <em>only</em>
those packages that <em>you</em> need directly. What
others need is their business. For example, if you
only link against <tt>libimlib</tt>, you will need to
build-depend on <package>libimlib2-dev</package> but
not against any <tt>libjpeg*</tt> packages, even
though <tt>libimlib2-dev</tt> currently depends on
them: installation of <package>libimlib2-dev</package>
will automatically ensure that all of its run-time
dependencies are satisfied.
</p>
</footnote>
-->
ビルド時依存のパッケージを指定する場合、目的のパッケージをビルドするのに直接必要であるもののみをリストアップするべきです。
ビルド時依存として挙げたパッケージが依存しているという理由でパッケージを列挙する必要はありません。
<footnote>
<p>
これは、もしそれらの依存関係が変化した場合であっても、あなたは
<em>自分</em> が直接必要なもの <em>だけ</em>
を列挙すれば済むからです。他のパッケージはその人達の責任です。
例えば、<tt>libimlib</tt> だけにリンクしたいならば、ビルド時依存を
<package>libimlib2-dev</package> に指定する必要がありますが、
<tt>libjpeg*</tt> パッケージに指定する必要はありません。これは
<tt>libimlib2-dev</tt> が現在 <tt>libjpeg*</tt> に依存していても、です。
<package>libimlib2-dev</package> パッケージをインストールすることで、実行時の依存関係が満たされることは自動的に保証されます。
</p>
</footnote>
</p>
<p>
<!-- If build-time dependencies are specified, it must be
possible to build the package and produce working binaries
on a system with only essential and build-essential
packages installed and also those required to satisfy the
build-time relationships (including any implied
relationships). In particular, this means that version
clauses should be used rigorously in build-time
relationships so that one cannot produce bad or
inconsistently configured packages when the relationships
are properly satisfied.
-->
ビルド時の依存関係が指定されている場合、<em>essential</em>
パッケージ、<em>build-essential</em>
パッケージ、及び依存関係を満たすためのパッケージが全て
(それらのパッケージが依存している物も含めて)
揃っているシステムでパッケージのビルドができなければいけません。
このことは、依存関係が正しく満たされている場合に、間違ったものや矛盾を含んだパッケージを作り出さないよう、ビルド時依存に対するバージョン番号が厳密に指定されるべきであることを意味します。
</p>
<sect1>
<!-- <heading>Changes to the upstream sources</heading> -->
<heading>アップストリームのソースへの変更</heading>
<p><!--
If changes to the source code are made that are not
specific to the needs of the Debian system, they should be
sent to the upstream authors in whatever form they prefer
so as to be included in the upstream version of the
package.</p>
-->
ソースコードへの変更が Debian
システムでの固有の必要によるものでないなら、アップストリームの作者にその作者たちが望む形でその変更を含めることができるよう、その変更を送るべきです。
</p>
<p>
<!-- If you need to configure the package differently for
Debian or for Linux, and the upstream source doesn't
provide a way to do so, you should add such configuration
facilities (for example, a new <prgn>autoconf</prgn> test
or <tt>#define</tt>) and send the patch to the upstream
authors, with the default set to the way they originally
had it. You can then easily override the default in your
<tt>debian/rules</tt> or wherever is appropriate.</p>
-->
パッケージを Debian もしくは Linux 向けに修正する必要があり、
アップストリームのソースがそれを行う手段を提供していない場合、
その機能を追加すべきです。(例えば <prgn>autoconf</prgn>
によるテストや <tt>#define</tt> 等)
そしてパッチをアップストリームの作者に送り、最初からその変更がなされているようにします。
そうすれば簡単にあなたの <tt>debian/rules</tt>
かどこか適当なところでデフォルトを置き換えることができます。
</p>
<p>
<!-- You should make sure that the <prgn>configure</prgn> utility
detects the correct architecture specification string
(refer to <ref id="arch-spec"> for details). -->
<prgn>configure</prgn> ユーティリティには正しくアーキテクチャを指定できる文字列を検出させるようにすべきです
(具体的には <ref id="arch-spec"> を参照)。
</p>
<p>
<!-- If you need to edit a <prgn>Makefile</prgn> where
GNU-style <prgn>configure</prgn> scripts are used, you
should edit the <tt>.in</tt> files rather than editing the
<prgn>Makefile</prgn> directly. This allows the user to
reconfigure the package if necessary. You should
<em>not</em> configure the package and edit the generated
<prgn>Makefile</prgn>! This makes it impossible for
someone else to later reconfigure the package.-->
もし、GNU の <prgn>configure</prgn> スクリプトが作る
<prgn>Makefile</prgn> を修正する必要にせまられた場合、直接
<prgn>Makefile</prgn> に手を加えずに <tt>.in</tt>
ファイルを変更しましょう。
こうすることでユーザーによるパッケージの再ビルドが可能となります。
あなたが <prgn>configure</prgn> を行い、
その後 <prgn>Makefile</prgn> を変更すれば、だれもそのあとでパッケージの再ビルドができなくなってしまいます。
そういったことはすべきではありません。
</p></sect1>
<sect1>
<!--
<heading>Documenting your changes</heading>
-->
<heading>あなたの行った変更を記述する</heading>
<p>
<!--
You should document your changes and updates to the source
package properly in the <tt>debian/changelog</tt> file.
(Note that mistakes in changelogs are usually best
rectified by making a new changelog entry rather than
"rewriting history" by editing old changelog entries.)
-->
あなたがソースパッケージに加えた変更や更新は、
<tt>debian/changelog</tt> ファイルに適切に記述しておくべきです。
(この記載が不十分であるというミスは、元々の
changelog エントリを編集して履歴を再作成して修正することもできますが、たいていの場合は新しい
changelog エントリを作成することにするほうがよりよい方法です。)
</p>
<p><!--
In non-experimental packages you must use a format for
format for <tt>debian/changelog</tt> which is supported by
the most recent released version of <prgn>dpkg</prgn>.
<footnote>
<p>
If you wish to use an alternative format, you may do
so as long as you include a parser for it in your
source package. The parser must have an API
compatible with that expected by
<prgn>dpkg-genchanges</prgn> and
<prgn>dpkg-gencontrol</prgn>. If there is general
interest in the new format, you should contact the
<package>dpkg</package> maintainer to have the parser
script for it included in the <prgn>dpkg</prgn>
package. (You will need to agree that the parser and
its manpage may be distributed under the GNU GPL, just
as the rest of `dpkg' is.)
</p>
</footnote>
-->
experimental ではないパッケージにおいては、
<tt>debian/changelog</tt> の書式としては、最新リリースの
<prgn>dpkg</prgn> がサポートしているものを使わなければなりません。
<footnote>
<p>
別なフォーマットを用いたい場合、そのパッケージのソースパッケージ中にパーザを含めておけば用いても構いません。
このパーザは <prgn>dpkg-genchanges</prgn> および
<prgn>dpkg-gencontrol</prgn> が期待しているものと API
互換である必要があります。
新しい書式が広く関心を引く (であろう) ものであるときには、
<prgn>dpkg</prgn> のメンテナに連絡をとり、その書式に対応するパーサを
<prgn>dpkg</prgn> パッケージに含めてもらうようにして下さい。
(そのパーサとマニュアルページは、<prgn>dpkg</prgn> の一部として
dpkg の他の部分同様 GNU GPL で配付することを認める必要があります)。
</p>
</footnote>
</p>
</sect1>
<sect1>
<!--
<heading>Error trapping in makefiles</heading>
-->
<heading>makefile でのエラーを捕捉する</heading>
<p>
<!--
When <prgn>make</prgn> invokes a command in a makefile
(including your package's upstream makefiles and
<tt>debian/rules</tt>), it does so using <tt>sh</tt>. This
means that <tt>sh</tt>'s usual bad error handling
properties apply: if you include a miniature script as one
of the commands in your makefile you'll find that if you
don't do anything about it then errors are not detected
and <prgn>make</prgn> will blithely continue after
problems.
-->
<prgn>make</prgn> が makefile (あなたのパッケージの上流が用意した
makefile も <tt>debian/rules</tt> も含む)
で指定されたコマンドを呼び出す際には、<tt>sh</tt> を使います。
このため、<tt>sh</tt> のエラー処理の出来が悪いという欠点が露呈してしまいます。
あなたの makefile に、そこから呼び出されるコマンドの一つとして小さなスクリプトが含まれている場合、
もし適切に手を打たなければエラーは何も検出されず、
<prgn>make</prgn> は問題が起こった後ものんきに処理を続けてしまうでしょう。
</p>
<p>
<!--
Every time you put more than one shell command (this
includes using a loop) in a makefile command you
must make sure that errors are trapped. For
simple compound commands, such as changing directory and
then running a program, using <tt>&&</tt> rather
than semicolon as a command separator is sufficient. For
more complex commands including most loops and
conditionals you should include a separate <tt>set -e</tt>
command at the start of every makefile command that's
actually one of these miniature shell scripts.
-->
一つ以上のシェルコマンド (これにはループの使用も該当します) を
makefile 内のコマンドとして使うときにはいつでも、
エラーが捕捉されているかどうか確かめなければなりません。
ディレクトリを移ってあるプログラムを実行する、というような単純な複合コマンドでは、コマンドセパレータとしてセミコロンを使うのではなく、
<tt>&&</tt> でつなげば十分でしょう。
多くのループや条件式といったより複雑なコマンド群に対しては、
実際にはこれらの小さなシェルスクリプトの一つを呼び出している
makefile コマンドのそれぞれの先頭に独立した <tt>set -e</tt>
を含めるべきです。
</p></sect1>
<sect1>
<!--
<heading>Obsolete constructs and libraries</heading>
-->
<heading>時代遅れになった構成物やライブラリの取り扱い</heading>
<p>
<!--
The include file <prgn><varargs.h></prgn> is
provided to support end-users compiling very old software;
the library <tt>libtermcap</tt> is provided to support the
execution of software which has been linked against it
(either old programs or those such as Netscape which are
only available in binary form).
-->
インクルードファイル <prgn><varargs.h></prgn>
は非常に古いソフトウェアをコンパイルするエンドユーザをサポートするために提供されています。
また、<tt>libtermcap</tt>
ライブラリはすでにそれに対してリンクされてしまっているソフトウェア
(古いプログラムか、あるいは Netscape
のようにバイナリ形式でしか入手できないもののどちらか)
の実行をサポートするために提供されています。
</p>
<p>
<!--
Debian packages should be patched to use
<prgn><stdarg.h></prgn> and <tt>ncurses</tt>
instead.
-->
Debian 用パッケージは、上記ファイルではなく
<prgn><stdarg.h></prgn> と <tt>ncurses</tt>
を使うように変更されるべきです。
</p>
</sect1>
</sect>
</chapt>
<!-- <chapt id="controlfields"><heading>Control files and their fields</heading>-->
<chapt id="controlfields"><heading>コントロールファイルと、その各フィールド</heading>
<p><!--
Many of the tools in the package management suite manipulate
data represented in a common format, known as <em>control
data</em>. The data is often stored in <em>control
files</em>. Binary and source packages have control files,
and the <tt>.changes</tt> files which control the installation
of uploaded files are also in control file format.
<prgn>Dpkg</prgn>'s internal databases are in a similar
format.-->
パッケージマネージメント関連の多くのツールは、<em>コントロールデータ</em>
として知られている共通のフォーマットのデータを操作します。
このデータは多くの場合、<em>コントロールファイル</em> 中に格納されます。
バイナリーおよびソースパッケージはアップロードされたファイルのディストリビューションへのインストールを制御するコントロールファイルと
<tt>.changes</tt> ファイルを持っています。
また、<prgn>dpkg</prgn> の内部のデータベースも同様のフォーマットです。
</p>
<sect><heading><!-- Syntax of control files-->コントロールファイルの書式</heading>
<p> <!--
A control file consists of one or more paragraphs of fields.
The paragraphs are separated by blank lines. Some control
files allow only one paragraph; others allow several, in
which case each paragraph usually refers to a different
package. (For example, in source packages, the first
paragraph refers to the source package, and later paragraphs
refer to binary packages generated from the source.)-->
コントロールファイルは、一つ以上のフィールドのパラグラフで構成されます。
パラグラフは、空白行によって分けられます。
いくつかのコントロールファイルは、一つのパラグラフのみを許します。
また別の場合には複数個を許しますが、その場合にそれぞれのパラグラフが異なるパッケージを参照することがしばしばあります
(例えば、ソースパッケージでは最初のパラグラフはソースパッケージを示し、以降のパラグラフではソースから生成されるバイナリパッケージを示します)。
</p>
<p> <!--
Each paragraph consists of a series of data fields; each
field consists of the field name, followed by a colon and
then the data/value associated with that field. It ends at
the end of the line. Horizontal whitespace (spaces and
tabs) may occur immediately before or after the value and is
ignored there; it is conventional to put a single space
after the colon. For example, a field might be:
<example>
Package: libc6
</example>
the field name is <tt>Package</tt> and the field value
<tt>libc6</tt>.-->
各パラグラフは、一連のフィールドと値からなります。
各フィールドは、フィールド名と、それに続くコロン、そのフィールドのデータないしは値から構成されます。
フィールドは行末で終了します。
水平方向の空白 (スペース、およびタブ) は、値の前後に置くことができ、無視されます。
コロンの後で一文字の空白を入れることは、慣行となっています。
例えば、フィールドは以下のようなものです。
<example>
Package: libc6
</example>
この場合、フィールド名は <tt>Package</tt> で、フィールドの値は
<tt>libc6</tt> です。
</p>
<p> <!--
Some fields' values may span several lines; in this case
each continuation line <em>must</em> start with a space or
tab. Any trailing spaces or tabs at the end of individual
lines of a field value are ignored.-->
いくつかのフィールドの値は、複数の行に及ぶかもしれません。
その場合それぞれの継続行は空白またはタブで始まっていなければ
<em>いけません</em>。
フィールド値の各行の終わりに続く空白およびタブは無視されます。
</p>
<p> <!--
Except where otherwise stated only a single line of data is
allowed and whitespace is not significant in a field body.
Whitespace must not appear inside names (of packages,
architectures, files or anything else) or version numbers,
or between the characters of multi-character version
relationships.-->
明確にそう記載されている場合を除いて、フィールド本体中のデータは一行のみが許され、空白は意味を持ちません。
パッケージ、アーキテクチャ、ファイルまたは他のものを示す名前中に空白を入れることはできません。
また、バージョン番号または、複数文字のバージョン関係を示す文字間に空白を入れることもできません。
</p>
<p> <!--
Field names are not case-sensitive, but it is usual to
capitalize the field names using mixed case as shown below.-->
フィールド名には、大／小文字の区別はありません。
しかし、慣習的に下記に記載のように大文字小文字を混ぜて用い、適宜大文字にするのが普通です。
</p>
<p> <!--
Blank lines, or lines consisting only of spaces and tabs,
are not allowed within field values or between fields - that
would mean a new paragraph.-->
空白行、あるいはスペースとタブだけを含む行はフィールド値の中、およびフィールド間では許されません。それは、新しいパラグラフを意味することになります。
</p>
</sect>
<sect><heading><!-- List of fields-->フィールドのリスト</heading>
<p><!--
This list here is not supposed to be exhaustive. Most fields
are dealt with elsewhere in this document.-->
ここで記載されたリストは網羅的なものではありません。
殆どのフィールドはこの文書の他の部分で扱われています。
</p>
<sect1 id="f-Package"><heading><tt>Package</tt>
</heading>
<p> <!--
The name of the binary package. Package names consist of
the alphanumerics and <tt>+</tt> <tt>-</tt> <tt>.</tt>
(plus, minus and full stop).-->
バイナリパッケージの名前です。
パッケージ名はアルファベット小文字、数字(0-9)、プラス (<tt>+</tt>)
記号、マイナス (<tt>-</tt>) 記号、あるいは
ピリオド (<tt>.</tt>) でのみ構成されていなければなりません。
</p>
<p> <!--
They must be at least two characters long and must start
with an alphanumeric character and not be all digits. The
use of lowercase package names is strongly recommended
unless the package you're building (or referring to, in
other fields) is already using uppercase.</p>-->
パッケージ名は少なくとも二文字で、英数字から始まっていなければならず、全部数字ではいけません。
作成しようとしているパッケージ (または他フィールドで参照しているもの)
に既に大文字が含まれている場合を除いては、すべて小文字のパッケージ名を使うことを強く推奨します。
</p>
</sect1>
<sect1 id="f-Version"><heading><tt>Version</tt>
</heading>
<p> <!--
This lists the source or binary package's version number -
see <ref id="versions">.-->
これは、バイナリパッケージのバージョン番号です。
<ref id="versions"> を参照ください。
</p>
</sect1>
<sect1
id="f-Standards-Version"><heading><tt>Standards-Version</tt>
</heading>
<p> <!--
The most recent version of the standards (the policy
manual and associated texts) with which the package
complies. This is updated manually when editing the
source package to conform to newer standards; it can
sometimes be used to tell when a package needs attention.
Its format is described above; see
<ref id="standardsversion">.-->
あなたのパッケージが準拠したパッケージング基準
(ポリシーマニュアルと関連の文書)
の最新バージョンを記載します。
これはソースパッケージを最新の標準に準拠するよう編集する際に手で修正する必要があります。
時には、パッケージのチェックを行う必要があることを知らせるのにも使えます。
このフォーマットはこの文書中に記載されています。
<ref id="standardsversion"> の項を参照ください。
</p>
</sect1>
<sect1 id="f-Distribution"><heading><tt>Distribution</tt>
</heading>
<p> <!--
In a <tt>.changes</tt> file or parsed changelog output
this contains the (space-separated) name(s) of the
distribution(s) where this version of the package should
be installed. Valid distributions are determined by the
archive maintainers.-->
<tt>.changes</tt> ファイル、または構文解析された changelog
の出力のこのフィールドには、このパッケージがインストールされていた、
またはこれからインストールされるディストリビューションの名前が
(複数ある場合は空白で区切られて) 含まれます
<footnote>
<!-- Current distribution names are:-->
現在、ディストリビューションの取り得る値は
<taglist>
<tag><em>stable</em></tag>
<item>
<p> <!--
This is the current `released' version of Debian
GNU/Linux. Once the distribution is
<em>stable</em> only security fixes and other
major bug fixes are allowed. When changes are
made to this distribution, the release number is
increased (for example: 2.2r1 becomes 2.2r2 then
2.2r3, etc).-->
これは、現在の Debian GNU/Linux のリリースバージョンです。
ディストリビューションが、stable (安定版)
になった後は、セキュリティ修正と大きなバグフィックスだけが許されます。
このディストリビューションに変更が加えられるときは、リリース番号が増えます
(例えば、1.2r1 は 1.2r2 になり、1.2r3 になります)。
</p>
</item>
<tag><em>unstable</em></tag>
<item>
<p><!--
This distribution value refers to the
<em>developmental</em> part of the Debian
distribution tree. New packages, new upstream
versions of packages and bug fixes go into the
<em>unstable</em> directory tree. Download from
this distribution at your own risk.-->
このディストリビューションは、Debian の配布ツリーの中で、<em>開発中</em> のものであるということを示します。
新しいパッケージおよびパッケージの上流の最新のバージョン、バグフィックスは、この <em>unstable</em> へ収録されます。
自己責任においてダウンロードしてください。
</p>
</item>
<tag><em>testing</em></tag>
<item>
<p><!--
This distribution value refers to the
<em>testing</em> part of the Debian distribution
tree. It receives its packages from the
unstable distribution after a short time lag to
ensure that there are no major issues with the
unstable packages. It is less prone to breakage
than unstable, but still risky. It is not
possible to upload packages directly to
<em>testing</em>.-->
このディストリビューション名は Debian
のディストリビューションのうち、<em>テスト</em>
中の部分を示します。このディストリビューションでは
unstable ディストリビューションからのパッケージを、
unstable 中で大きな問題が発生しないことを確認する短い猶予期間をおいて、受け入れます。
これは unstable よりは問題が起こる可能性は少ないでしょうが、危険性は残っています。
パッケージを直接 <em>testing</em>
にアップロードすることはできません。
</p>
</item>
<tag><em>frozen</em></tag>
<item>
<p><!--
From time to time, the <em>frozen</em>
distribution enters a state of `code-freeze' in
anticipation of release as a <em>stable</em>
version. During this period of testing only
fixes for existing or newly-discovered bugs will
be allowed. The exact details of this stage are
determined by the Release Manager.-->
潮時を見て <em>unstable</em> ディストリビューションは
<em>stable</em> としてリリースするための準備のため、
`code-freeze' 状態に移行します。
この期間は現時点ですでに分かっていたり、新たに発見されたバグの修正のみ許されます。
この段階の詳細はリリースマネージャが決定します。
<!-- 原文がどうしようもなく変なので、訳修正せず
frozen -> testing でしょうが……… -->
</p>
</item>
<tag><em>experimental</em></tag>
<item>
<p><!--
The packages with this distribution value are
deemed by their maintainers to be high
risk. Oftentimes they represent early beta or
developmental packages from various sources that
the maintainers want people to try, but are not
ready to be a part of the other parts of the
Debian distribution tree. Download at your own
risk.-->
このディストリビューションのパッケージは、メンテナから、ハイリスクであると宣言されています。
しばしば、様々な出所の初期のβ版や開発中のパッケージであって、メンテナとしては他の人に試してほしいと考えてはいるものも、Debian
の他のディストリビューションに含めてよいだけの完成度ではないものが含まれています。
自己責任においてダウンロードしてください。
</p>
</item>
</taglist>
<!-- You should list <em>all</em> distributions that the
package should be installed into.-->
このフィールドには、そのパッケージがインストールされる、<em>すべて</em> のディストリビューションを列挙しなければいけません。
</footnote>
。
有効なディストリビューションの名前は、アーカイブメンテナが決定します。
</p>
</sect1>
</sect>
</chapt>
<!--<chapt id="versions"><heading>Version numbering </heading>-->
<chapt id="versions"><heading>Version <!--numbering -->番号付け</heading>
<p><!--
Every package has a version number recorded in its
<tt>Version</tt> control file field.-->
全てのパッケージは、コントロールファイルの <tt>Version</tt> フィールドにバージョン番号を持っています。
</p>
<p> <!--
The package management system imposes an ordering on version
numbers, so that it can tell whether packages are being up- or
downgraded and so that package system front end applications
can tell whether a package it finds available is newer than
the one installed on the system. The version number format
has the most significant parts (as far as comparison is
concerned) at the beginning.-->
パッケージ管理システムはバージョン番号に従った順序付けを行い、
これによってパッケージがアップグレードされるのか、
あるいはダウングレードされるのかを知ることができ、
さらにパッケージフロントエンドプログラムが、
あるパッケージがシステムにインストールされているものよりも新しいものかどうかを判断することができるようになります。
バージョン番号の形式は (比較に関する限り)
重要なものが前にくる順となっています。
</p>
<p>
<!-- The version number format is:-->バージョン番号のフォーマットは、
&lsqb<var>epoch</var><tt>:</tt>]<var>upstream_version</var>[<tt>-</tt><var>debian_revision</var>]
です。
</p>
<p>
<!-- The three components here are:-->バージョンを構成する 3 つの要素は
<taglist>
<tag><var>epoch</var></tag>
<item>
<p><!--
This is a single (generally small) unsigned integer. It
may be omitted, in which case zero is assumed. If it is
omitted then the <var>upstream_version</var> may not
contain any colons.-->
これは1桁の符号なし整数です。普通は小さい数になるはずです。
ゼロと仮定して良い場合は省略できます。省略した時には、
<var>upstream_version</var> にコロンを含めてはいけません。
</p>
<p> <!--
It is provided to allow mistakes in the version numbers
of older versions of a package, and also a package's
previous version numbering schemes, to be left behind.-->
これはパッケージの古いバージョンのバージョン番号の誤りを許したり、
パッケージの以前のバージョン番号体系をそのままに残しておくためにあります。
</p>
</item>
<tag><var>upstream_version</var></tag>
<item>
<p><!--
This is the main part of the version number. It is
usually the version number of the original (`upstream')
package from which the <tt>.deb</tt> file has been made,
if this is applicable. Usually this will be in the same
format as that specified by the upstream author(s);
however, it may need to be reformatted to fit into the
package management system's format and comparison
scheme.-->
これがバージョン番号の主要部分です。通常支障ない場合は
<tt>.deb</tt> ファイルが作られたオリジナルの (`上流の')
パッケージのバージョン番号になります。
普通は上流の作者によって定められたものと同じ形式になりますが、
パッケージ管理システムと比較手法に沿って修正を加えなければならないかもしれません。
</p>
<p> <!--
The comparison behavior of the package management system
with respect to the <var>upstream_version</var> is
described below. The <var>upstream_version</var>
portion of the version number is mandatory.-->
<var>upstream_version</var> に関するパッケージ管理システムの比較の挙動については次節で述べます。
バージョン番号中で、この <var>upstream_version</var>
の部分は必須です。
</p>
<p> <!--
The <var>upstream_version</var> may contain only
alphanumerics
<footnote>
<p>Alphanumerics are <tt>A-Za-z0-9</tt> only.</p>
</footnote>
and the characters <tt>.</tt> <tt>+</tt> <tt>-</tt>
<tt>:</tt> (full stop, plus, hyphen, colon) and should
start with a digit. If there is no
<var>debian_revision</var> then hyphens are not allowed;
if there is no <var>epoch</var> then colons are not
allowed.-->
<var>upstream_version</var> は英数字
<footnote>
<p>英数字は <tt>A-Za-z0-9</tt> のみです。</p>
</footnote>
と文字 <tt>.</tt> <tt>+</tt>
<tt>-</tt> <tt>:</tt> (ピリオド、プラス、ハイフン、コロン)
だけから構成されており、数字で始まるようにすべきです。
ただし、<var>debian_revision</var> がない場合、ハイフンは許されません。
また、<var>epoch</var> がない場合、コロンは許されません。
</p>
</item>
<tag><var>debian_revision</var></tag>
<item>
<p><!--
This part of the version number specifies the version of
the Debian package based on the upstream version. It
may contain only alphanumerics and the characters
<tt>+</tt> and <tt>.</tt> (plus and full stop) and is
compared in the same way as the
<var>upstream_version</var> is.-->
バージョンのこの部分は、そのパッケージを Debian
バイナリパッケージにするためにほどこした修正のバージョン番号を表わしています。
これは英数字と <tt>+</tt> と <tt>.</tt> (プラスとピリオド)
の二記号のみからなり、<var>upstream_version</var>
と同じやり方で比較されます。
</p>
<p> <!--
It is optional; if it isn't present then the
<var>upstream_version</var> may not contain a hyphen.
This format represents the case where a piece of
software was written specifically to be turned into a
Debian binary package, and so there is only one
Debian package, and so there is only one `debianization'
of it and therefore no revision indication is required.-->
これはオプションです。
<var>debian-revision</var> を持たない場合には、
<var>upstream-version</var> はハイフンを含んでいてはいけません。
この <var>debian-revision</var> を持たない形式のものは
Debian バイナリパッケージになるように特別に書かれたソフトウェアであることを示しています。
そのようなソフトウェアの `Debian化' は一つだけですから、レビジョンの追加は必要ありません。
</p>
<p> <!--
It is conventional to restart the
<var>debian_revision</var> at <tt>1</tt> each time the
<var>upstream_version</var> is increased.-->
<var>upstream_version</var> が増加するたびに、
<var>debian_revision</var> を <tt>1</tt> に戻すのが慣習となっています。
</p>
<p> <!--
The package management system will break the version
number apart at the last hyphen in the string (if there
is one) to determine the <var>upstream_version</var> and
<var>debian_revision</var>. The absence of a
<var>debian_revision</var> compares earlier than the
presence of one (but note that the
<var>debian_revision</var> is the least significant part
of the version number).
-->
パッケージ管理システムは文字列中の最後のハイフン (あれば)
のところでバージョン番号を <var>upstream_version</var> と
<var>debian_revision</var> とに分割しようとします。
<var>debian_revision</var> がないものは、それがあるものより以前のものであるとして比較されます
(ここでの記載に関わらず、<var>debian_revision</var>
はバージョン番号の最下位部分であることに注意して下さい)。
</p>
</item>
</taglist>
<!-- The <var>upstream_version</var> and <var>debian_revision</var>
parts are compared by the package management system using the
same algorithm: -->
<var>upstream_version</var> と <var>debian_revision</var> の部分はパッケージ管理システムから同じアルゴリズムを用いて比較されます。
</p>
<p>
<!-- The strings are compared from left to right.-->
文字列は左から右へと比較されます。
</p>
<p> <!--
First the initial part of each string consisting entirely of
non-digit characters is determined. These two parts (one of
which may be empty) are compared lexically. If a difference
is found it is returned. The lexical comparison is a
comparison of ASCII values modified so that all the letters
sort earlier than all the non-letters.-->
最初に、比較対象となる2つの文字列の中で、全て非数字で構成される最初の部分を決定します。
両方の文字列に対する、この数字でない部分 (そのうちの一つは空であっても構いません) を辞書順で比較します。もし違いが見つかれば、それを返します。
ここでの辞書順とは、すべての文字が非文字より先に来る様に修正した ASCII 順です。
</p>
<p> <!--
Then the initial part of the remainder of each string which
consists entirely of digit characters is determined. The
numerical values of these two parts are compared, and any
difference found is returned as the result of the comparison.
For these purposes an empty string (which can only occur at
the end of one or both version strings being compared) counts
as zero.-->
次に、2 つの文字列の残りの部分から、全て数字で構成される最初の部分を決定します。この2つの数値を比較し、比較結果として見つかった違いを返します。
このとき、空文字列 (比較している一方もしくは双方のバージョン文字列の末尾においてのみ生じる) は 0 として数えます。
</p>
<p> <!--
These two steps (comparing and removing initial non-digit
strings and initial digit strings) are repeated until a
difference is found or both strings are exhausted.-->
違いが見つかるか、双方の文字列を調べ尽くすかするまで、この2つのステップを
(先頭から、最初の非数字の文字列と最初の数字の文字列を比較し、切り離しながら) 繰り返します。
</p>
<p> <!--
Note that the purpose of epochs is to allow us to leave behind
mistakes in version numbering, and to cope with situations
where the version numbering scheme changes. It is
<em>not</em> intended to cope with version numbers containing
strings of letters which the package management system cannot
interpret (such as <tt>ALPHA</tt> or <tt>pre-</tt>), or with
silly orderings (the author of this manual has heard of a
package whose versions went <tt>1.1</tt>, <tt>1.2</tt>,
<tt>1.3</tt>, <tt>1</tt>, <tt>2.1</tt>, <tt>2.2</tt>,
<tt>2</tt> and so forth).
-->
epoch の目的はバージョン番号付けのミスをそのままにできるようにするため、またバージョン番号の付け方を変更した場合にそれをうまく扱えるようにするためだということに注意してください。
パッケージ管理システムが解釈することのできない文字
(<tt>ALPHA</tt> や <tt>pre-</tt> など) から成る文字列を含むバージョン番号や、思慮の浅い順序付け
(このマニュアルの著者は、<tt>1.1</tt>、<tt>1.2</tt>、<tt>1.3</tt>、<tt>1</tt>、<tt>2.1</tt>、<tt>2.2</tt>、<tt>2</tt> とバージョンが進んでいったパッケージのことを聞いたことがあります) をうまく処理するためでは <em>ありません</em>。
</p>
<p> <!--
If an upstream package has problematic version numbers they
should be converted to a sane form for use in the
<tt>Version</tt> field.-->
もし上流のパッケージが問題のあるバージョン番号形式になっているならば、<tt>Version</tt> フィールドではまともな形式に変換すべきです。
</p>
<sect>
<heading><!-- Version numbers based on dates-->日付に基づくバージョン番号</heading>
<p><!--
In general, Debian packages should use the same version
numbers as the upstream sources.-->
一般的に、Debian パッケージは上流ソースと同じバージョン番号を使うべきです。
</p>
<p><!--
However, in some cases where the upstream version number is
based on a date (e.g., a development `snapshot' release) the
package management system cannot handle these version
numbers without epochs. For example, dpkg will consider
`96May01' to be greater than `96Dec24'.-->
しかし、上流のバージョン番号が日付に基づくような場合
(例えば、開発中の `snapshot' リリースの場合) には、パッケージ管理システムはこのようなバージョン番号を epoch を使わずに扱うことはできません。
例えば、dpkg は `96May01' を `96Dec24'
よりも大きいと判断するでしょう。
</p>
<p><!--
To prevent having to use epochs for every new upstream
version, the version number should be changed to the
following format in such cases: `19960501', `19961224'. It
is up to the maintainer whether he/she wants to bother the
upstream maintainer to change the version numbers upstream,
too.-->
そのような場合に、今後の新しい上流バージョンに対して epoch を使わなくて済むようにするためには、バージョン番号を `19960501'、`19961224'
といった書式に変更すべきです。上流のメンテナに、上流のバージョン番号も変更するようにお願いするかどうかはメンテナ次第です。
</p>
<p><!--
Note that other version formats based on dates which are
parsed correctly by the package management system should
<em>not</em> be changed.-->
日付に基づいた、このほかのバージョン番号の書式がパッケージ管理システムによって正しく解析されるなら、そのバージョン番号を変更
<em>すべきでない</em> ことに注意して下さい。
</p>
<p><!--
Native Debian packages (i.e., packages which have been
written especially for Debian) whose version numbers include
dates should always use the `YYYYMMDD' format.-->
Debian 固有のパッケージ (つまり、Debian 向けに特別に書かれたパッケージ) のバージョン番号に日付を含めるならば、 常に `YYYYMMDD' という書式を使うべきです。
</p>
</sect>
</chapt>
<chapt id="miscellaneous"><heading><!--Packaging Considerations-->パッケージング時の考慮点</heading>
<sect id="timestamps"><heading><!--Time Stamps-->タイムスタンプ</heading>
<p><!--
Maintainers should preserve the modification times of the
upstream source files in a package, as far as is reasonably
possible.
Maintainers are encouraged to preserve the modification
times of the upstream source files in a package, as far as
is reasonably possible. Even though this is optional, this
is still a good idea. -->
メンテナは可能な限り上流のソースファイルファイルの更新時刻をパッケージ中で変更しないでおくべきです
<footnote>
<p><!--
The rationale is that there is some information conveyed
by knowing the age of the file, for example, you could
recognize that some documentation is very old by looking
at the modification time, so it would be nice if the
modification time of the upstream source would be
preserved.-->
タイムスタンプを保持する理由付けとしては、ファイルの作成時間を知ることによって伝わる情報があるからです。
例えば、ある文書の修正時間を見ることによって、それが非常に古いものであることを知ることができる、などです。
ですから、上流のソースの修正時間を保持しておくのはとても良いことです。
</p>
</footnote>
。</p>
</sect>
<sect id="debianrules"><heading><tt>debian/rules</tt> - <!--the
main building script-->メインのビルドスクリプト</heading>
<p> <!--
This file must be an executable makefile, and contains the
package-specific recipes for compiling the package and
building binary package(s) from the source.-->
このファイルは実行可能な makefile
で、ソースからパッケージをコンパイルしバイナリパッケージをビルドするためのパッケージ特有のレシピを含んでいなければいけません。
</p>
<p> <!--
It must start with the line <tt>#!/usr/bin/make -f</tt>,
so that it can be invoked by saying its name rather than
invoking <prgn>make</prgn> explicitly.-->
このファイルの先頭は <tt>#!/usr/bin/make -f</tt> という行で始まっていなければなりません。<prgn>make</prgn> を明示的に実行するのではなく、`debian/rules' という名前で実行できるようにする為です。
</p>
<p><!--
Since an interactive <tt>debian/rules</tt> script makes it
impossible to auto-compile that package and also makes it
hard for other people to reproduce the same binary
package, all <strong>required targets</strong> MUST be
non-interactive. At a minimum, required targets are the
ones called by <prgn>dpkg-buildpackage</prgn>, namely,
<em>clean</em>, <em>binary</em>, <em>binary-arch</em>,
<em>binary-indep</em>, and
<em>build</em>. It also follows that any target that these
targets depend on must also be non-interactive.-->
対話型の <tt>debian/rules</tt>
スクリプトは、そのパッケージの自動コンパイルを不可能にし、さらにメンテナー以外の人が同じバイナリパッケージを再ビルドするのを難しくします。
ですから、全ての <strong>必要なターゲット</strong> は非対話的でなくてはなりません。
最小限の範囲で言えば、必要なターゲットとは、<prgn>dpkg-buildpackage</prgn> から呼び出されるターゲット、つまり <em>clean</em>、<em>binary</em>、
<em>binary-arch</em>、<em>binary-indep</em>、<em>build</em> のことです。
また、これらのターゲットが依存するターゲットも非対話的なものでなければいけません。
</p>
<p>
<!-- The targets which must be present are: -->
定義が必要なターゲットは次の通りです。
<taglist>
<tag><tt>build</tt></tag>
<item>
<p><!--
This should perform all non-interactive configuration
and compilation of the package. If a package has an
interactive pre-build configuration routine, the
Debianized source package must either be built after
this has taken place (so that the binary package can
be built without rerunning the configuration) or the
configuration routine modified to become
non-interactive. (The latter is preferable if there
are architecture-specific features detected by the
configuration routine.)
-->
パッケージの構築 (ビルド)、すなわち全てのパッケージの非対話的な設定とコンパイルを行ないます。
もしパッケージに対話型のビルド前の設定ルーチンがある場合は、Debian
化されたソースパッケージは設定作業を行なった後でビルドするか
(これは、設定を再びせずにバイナリパッケージをビルド出来るようにするためです)、設定ルーチンを非対話型になるように変更しなければいけません。
アーキテクチャ固有の機能の検出が設定ルーチンで行われるようになっている場合は、後者の方が適切です。
</p>
<p> <!--
For some packages, notably ones where the same
source tree is compiled in different ways to produce
two binary packages, the <prgn>build</prgn> target
does not make much sense. For these packages it is
good enough to provide two (or more) targets
(<tt>build-a</tt> and <tt>build-b</tt> or whatever)
for each of the ways of building the package, and a
<prgn>build</prgn> target that does nothing. The
<prgn>binary</prgn> target will have to build the
package in each of the possible ways and make the
binary package out of each.-->
いくつかのパッケージでは、同一のソースツリーからコンパイルのやり方を変えることで異なった二つのバイナリパッケージを生成する場合があります。
<prgn>build</prgn> ターゲットは、そういう場合には対応できません。
これらの場合では、それぞれのビルド方法に対応した二つまたはそれ以上のターゲット
(<tt>build-a</tt> と <tt>build-b</tt> やその他) と、何も実行しない <prgn>build</prgn> ターゲットを用意するのがよいでしょう。
この場合は <prgn>binary</prgn> ターゲットで、各々のやり方でパッケージをビルドして、それぞれに対応したバイナリパッケージを生成することになります。
</p>
<p><!--
The <prgn>build</prgn> target must not do anything
that might require root privilege.-->
ルート権限が必要なことを <prgn>build</prgn> ターゲットで実行してはいけません。
</p>
<p> <!--
The <prgn>build</prgn> target may need to run the
<prgn>clean</prgn> target first - see below.
-->
また、<prgn>build</prgn> ターゲットの実行前には、<prgn>clean</prgn>
ターゲットを実行しなければならないでしょう。以降の節を参照ください。
</p>
<p> <!--
When a package has a configuration and build routine
which takes a long time, or when the makefiles are
poorly designed, or when <prgn>build</prgn> needs to
run <prgn>clean</prgn> first, it is a good idea to
<tt>touch build</tt> when the build process is
complete. This will ensure that if <tt>debian/rules
build</tt> is run again it will not rebuild the whole
program.
<footnote>
<p>
Another common way to do this is for <prgn>build</prgn>
to depend on <prgn>build-stamp</prgn> and to do
nothing else, and for the <prgn>build-stamp</prgn>
target to do the building and to <tt>touch
build-stamp</tt> on completion. This is
especially useful if the build routine creates a
file or directory called <tt>build</tt>; in such a
case, <prgn>build</prgn> will need to be listed as
a phony target (i.e., as a dependency of the
<tt>.PHONY</tt> target). See the documentation of
<prgn>make</prgn> for more information on phony
targets.
</p>
</footnote> -->
パッケージの設定やビルドルーチンに長い時間がかかる時や、makefile
があまり良く設計されていない時、 または <prgn>build</prgn> の前に
<prgn>clean</prgn> の実行が必要な時、ビルドプロセスの終了時に
<tt>touch build</tt> を実行しておくのがよいでしょう。
これによって、<tt>debian/rules build</tt> が再度実行されたときに、プログラム全体を再ビルドしなくてすみます
<footnote>
<p>
同様のことを行う際によく使われている別法に、
<prgn>build</prgn> を <prgn>build-stamp</prgn>
に依存し、かつ何もしないようにしておき、
<prgn>build-stamp</prgn> で実際のビルド処理と
<tt>touch build-stamp</tt>
を終了時に実行するようにするやり方があります。
これは、ビルドルーチンが <tt>build</tt>
という名のファイルやディレクトリを作成するようになっている場合、特に有効です。
この場合、<prgn>build</prgn> は偽ターゲットとして登録
(具体的には、<tt>.PHONY</tt> への依存関係を定義します)
しておく必要があります。偽ターゲットの詳細については、
<prgn>make</prgn> のドキュメントを参照ください。
</p>
</footnote>
。
</p>
</item>
<tag><tt>binary</tt>, <tt>binary-arch</tt>,
<tt>binary-indep</tt>
</tag>
<item>
<p><!--
The <prgn>binary</prgn> target must be all that is
necessary for the user to build the binary package(s)
produced from this source package. All of these
targets are required to be non-interactive. It is
split into two parts: <prgn>binary-arch</prgn> builds
the binary packages which are specific to a particular
architecture, and <prgn>binary-indep</prgn> builds
those which are not.-->
<prgn>binary</prgn> ターゲットは、ユーザがこれだけでソースパッケージから生成されるバイナリパッケージ
(複数のこともあります) をビルドできるようなものでなければいけません。
これらのすべてのターゲットは、非対話的に動作するものでなければなりません。
<prgn>binary</prgn> ターゲットは、二つの部分に分けられます:
<prgn>binary-arch</prgn> は、特定のアーキテクチャ用のファイル、
<prgn>binary-indep</prgn> は、それ以外のものを生成します。
</p>
<p> <!--
<prgn>binary</prgn> may be (and commonly is) a target
with no commands which simply depends on
<prgn>binary-arch</prgn> and
<prgn>binary-indep</prgn>.-->
<prgn>binary</prgn> は、コマンドなしで単純に
<prgn>binary-arch</prgn> と <prgn>binary-indep</prgn>
に依存するようなパッケージであることは許されますし、また普通のパッケージではそのようになっています。
</p>
<p><!--
Each <prgn>binary-*</prgn> target should depend on
the <prgn>build</prgn> target, above, so that the
package is built if it has not been already. It
should then create the relevant binary package(s),
using <prgn>dpkg-gencontrol</prgn> to make their
control files and <prgn>dpkg-deb</prgn> to build
them and place them in the parent of the top level
directory.-->
両方の <prgn>binary-*</prgn> ターゲットは、 <prgn>build</prgn> ターゲットに依存すべきです。
このようにしておけば、もしパッケージビルド処理が済んでいないときはビルド処理が実施されます。
そしてその後 <prgn>dpkg-gencontrol</prgn> を使ってコントロールファイルを作成し、<prgn>dpkg-deb</prgn> でビルドを行って関連したバイナリパッケージを生成し、それをトップレベルディレクトリの親ディレクトリ中に置くべきです。
</p>
<p> <!--
Both the <prgn>binary-arch</prgn> and
<prgn>binary-indep</prgn> targets <em>must</em> exist.
If one of them has nothing to do (which will always be
the case if the source generates only a single binary
package, whether architecture-dependent or not), it
must still exist and must always succeed.-->
<prgn>binary-arch</prgn> と <prgn>binary-indep</prgn>
の両方のターゲットが <em>存在しなければいけません</em>。
このうち一方がなにも作成するものがない場合
(アーキテクチャ依存、非依存に関わらずソースから一つのバイナリパッケージしか生成しない場合がこれに当たります)
でも、両方のターゲットが存在しなければなりませんし、また処理が成功したというあつかいとしなければなりません。
</p>
<p> <!--
The <prgn>binary</prgn> targets must be invoked as
root.
<footnote>
<p>
The <prgn>fakeroot</prgn> package often allows one
to build a package correctly even without being
root.
</p>
</footnote>
-->
<prgn>binary</prgn> ターゲットは、ルート権限で起動されなければ
<footnote>
<p>
たいていの場合、<prgn>fakeroot</prgn>
パッケージを使えばルートにならずともパッケージを正しくビルドできます。
</p>
</footnote>
いけません。
</p>
</item>
<tag><tt>clean</tt></tag>
<item>
<p><!--
This must undo any effects that the <prgn>build</prgn>
and <prgn>binary</prgn> targets may have had, except
that it should leave alone any output files created in
the parent directory by a run of a <prgn>binary</prgn>
target. This target must be non-interactive.-->
<prgn>build</prgn> と <prgn>binary</prgn>
ターゲットによる実行結果を元に戻します。
ただし、<prgn>binary</prgn> ターゲットの実行により親ディレクトリに作成された出力ファイルはそのまま残します。
このターゲットは、非対話的でなければいけません。
</p>
<p> <!--
If a <prgn>build</prgn> file is touched at the end of
the <prgn>build</prgn> target, as suggested above, it
should be removed as the first action that
<prgn>clean</prgn> performs, so that running
<prgn>build</prgn> again after an interrupted
<prgn>clean</prgn> doesn't think that everything is
already done.-->
<prgn>build</prgn> ファイルが、前の項で述べたように、<prgn>build</prgn> ターゲット処理の最後に touch
されて作成されていた場合、そのファイルは、<prgn>clean</prgn> の最初の作業として削除するべきです。
中断された <prgn>clean</prgn> の後に <prgn>build</prgn> が 実行された場合、すべてが終了したと認識されてしまいかねないからです。
</p>
<p> <!--
The <prgn>clean</prgn> target may need to be
invoked as root if <prgn>binary</prgn> has been
invoked since the last <prgn>clean</prgn>, or if
<prgn>build</prgn> has been invoked as root (since
<prgn>build</prgn> may create directories, for
example).-->
<prgn>build</prgn> ターゲットがルート権限で実行されたあと、及び <prgn>binary</prgn> ターゲットが実行された後には、<prgn>clean</prgn>
ターゲットはルート権限で起動する必要があるかもしれません
(例えば、<prgn>clean</prgn> はディレクトリを作成することもあるからです)。
</p>
</item>
<tag><tt>get-orig-source</tt> (optional)</tag>
<item>
<p> <!--
This target fetches the most recent version of the
original source package from a canonical archive site
(via FTP or WWW, for example), does any necessary
rearrangement to turn it into the original source
tar file format described below, and leaves it in the
current directory.-->
主要なアーカイブサイトから最新版のオリジナルソースパッケージを取得します
(FTP や WWW経由)。
これをオリジナルのソースの tar ファイル形式
(下記参照) に再構成し、現在のディレクトリに置きます。
</p>
<p> <!--
This target may be invoked in any directory, and
should take care to clean up any temporary files it
may have left.-->
このターゲットは、どのディレクトリからも実行しても構いません。また残した一時ファイルを削除するよう気を遣うべきです。
</p>
<p> <!--
This target is optional, but providing it if
possible is a good idea.-->
このターゲットはオプションです。 しかしできる限りつけた方がよいでしょう。
</p>
</item>
</taglist>
<p><!--
The <prgn>build</prgn>, <prgn>binary</prgn> and
<prgn>clean</prgn> targets must be invoked with the current
directory being the package's top-level directory.-->
The <prgn>build</prgn>、<prgn>binary</prgn> 及び <prgn>clean</prgn>
ターゲットはパッケージのトップディレクトリをカレントディレクトリとして実行されなければいけません。
</p>
<p> <!--
Additional targets may exist in <tt>debian/rules</tt>,
either as published or undocumented interfaces or for the
package's internal use.-->
公開されている、またはいないインターフェースのためや、パッケージ内部で使用するために <tt>debian/rules</tt> に他のターゲットを置くことは許されます。
</p>
<p><!--
The architectures we build on and build for are determined
by <prgn>make</prgn> variables using the utility
<prgn>dpkg-architecture</prgn>. You can determine the
Debian architecture and the GNU style architecture
specification string for the build machine (the machine type
we are building on) as well as for the host machine (the
machine type we are building for). Here is a list of
supported <prgn>make</prgn> variables:-->
パッケージを実際にビルドするマシンや、インストールの対象となるマシンのアーキテクチャは、<prgn>dpkg-architecture</prgn>
を使って <prgn>make</prgn> 変数を設定することによって決定されます。
これにより、ホストマシン (パッケージの作成対象としているマシンタイプ)
だけでなくパッケージのビルドをするマシン
(ビルド作業に使っているマシン) の Debian 形式のアーキテクチャと
GNU 形式のアーキテクチャ指定文字列を得ることができます。
次に、サポートされている <prgn>make</prgn> 変数を示します。
<list compact="compact">
<item>
<p><tt>DEB_*_ARCH</tt> <!--(the Debian architecture)-->(Debian 形式のアーキテクチャ)</p>
</item>
<item>
<p><tt>DEB_*_GNU_TYPE</tt> <!-- (the GNU style architecture
specification string)-->(GNU 形式アーキテクチャ指定文字列)</p>
</item>
<item><!--
<p><tt>DEB_*_GNU_CPU</tt> (the CPU part of
<tt>DEB_*_GNU_TYPE</tt>)</p>-->
<p><tt>DEB_*_GNU_CPU</tt> (<tt>DEB_*_GNU_TYPE</tt> の CPU の部分)</p>
</item>
<item><!--
<p><tt>DEB_*_GNU_SYSTEM</tt> (the System part of
<tt>DEB_*_GNU_TYPE</tt>)</p>-->
<p><tt>DEB_*_GNU_SYSTEM</tt> (<tt>DEB_*_GNU_TYPE</tt> の システムの部分)</p>
</list>
</p>
<p><!--
where <tt>*</tt> is either <tt>BUILD</tt> for specification of
the build machine or <tt>HOST</tt> for specification of the
host machine.-->
<tt>*</tt> は <tt>BUILD</tt> か <tt>HOST</tt> のどちらかです。
<tt>BUILD</tt> の場合はパッケージをビルドするマシンの指定になり、
<tt>HOST</tt> の場合にはホストマシンの指定になります。
</p>
<p><!--
Backward compatibility can be provided in the rules file
by setting the needed variables to suitable default
values; please refer to the documentation of
<prgn>dpkg-architecture</prgn> for details.-->
rules ファイル中で必要な変数に適切な既定値を設定することによって、後方互換性を保つことができます。
詳しくは <prgn>dpkg-architecture</prgn> のドキュメントを参照して下さい。
</p>
<p><!--
It is important to understand that the <tt>DEB_*_ARCH</tt>
string only determine which Debian architecture we
build on or for. for. It should not be used to get the CPU
or System information, the GNU style variables should be
used for that.-->
<tt>DEB_*_ARCH</tt> は、ビルドするまたはビルド対象となるマシンの Debian アーキテクチャのみを決定するのだということを理解しておくことは重要です。
CPU や システムの情報を得るのにこれを使ってはいけません。
その場合には GNU 書式の変数を使わなくてはいけません。
</p>
</sect>
<sect id="dpkgchangelog"><heading><tt>debian/changelog (変更履歴)</tt>
</heading>
<p> <!--
This file records the changes to the Debian-specific parts of the
package-->
このファイルは、パッケージの Debian 特有の部分の変更を
<footnote>
<p><!--
Though there is nothing stopping an author who is also
the Debian maintainer from using it for all their
changes, it will have to be renamed if the Debian and
upstream maintainers become different people. In such a
case, however, it might be better to maintain the
package as a non-native package.-->
changelog の著者がパッケージの保守担当者でもある場合、パッケージの全ての変更に対してこの changelog
を使うようにすることもできますが、その場合にはパッケージや元のソースの保守担当者が違う人になった時には、名前を変更しなければなりません。
但し、そのような場合にはそのパッケージを Debian
向けのパッケージとはせずに保守した方がより良いでしょう。
</p>
</footnote>
記録します。</p>
<p> <!--
It has a special format which allows the package building
tools to discover which version of the package is being
built and find out other release-specific information.
-->
このファイルは特別な書式を持っています。これは、どのパッケージのバージョンが現在ビルド中なのかと、その他のリリース特有の情報を、パッケージビルドツールが認識できるようにするためです。
</p>
<p>
<!--That format is a series of entries like this: -->
この書式は次に示すものがひとつらなりになったものです。
<!--<example>
<var>package</var> (<var>version</var>) <var>distribution(s)</var>; urgency=<var>urgency</var>
* <var>change details</var>
<var>more change details</var>
* <var>even more change details</var>
-- <var>maintainer name and email address</var> <var>date</var>
</example>
-->
<example>
<var>パッケージ名</var> (<var>バージョン</var>) <var>ディストリビューション</var>; urgency=<var>緊急度</var>
* <var>変更内容</var>
<var>変更内容の続き</var>
* <var>また別の変更内容</var>
-- <var>メンテナ名と電子メールアドレス</var> <var>日付</var>
</example>
</p>
<p>
<!-- <var>package</var> and <var>version</var> are the source
package name and version number.-->
<var>package</var> と <var>version</var> は ソースパッケージの名前とバージョンです。
</p>
<p>
<var>distribution(s)</var> <!-- lists the distributions where
this version should be installed when it is uploaded - it
is copied to the <tt>Distribution</tt> field in the
<tt>.changes</tt> file. See <ref id="f-Distribution">.-->
には、このバージョンがアップロードされるときにインストールされるディストリビューションがリストされます - これらは、<tt>.changes</tt>
ファイルの <tt>Distribution</tt> フィールド にコピーされます。
<ref id="f-Distribution"> をご覧ください。
</p>
<p>
<!-- <var>urgency</var> is the value for the <tt>Urgency</tt>
field in the <tt>.changes</tt> file for the upload. It is
not possible to specify an urgency containing commas; commas
are used to separate
<tt><var>keyword</var>=<var>value</var></tt> settings in the
<prgn>dpkg</prgn> changelog format (though there is
currently only one useful <var>keyword</var>,
<tt>urgency</tt>).
<footnote>
<p>
Usual urgency values are <tt>low</tt>, <tt>medium</tt>,
<tt>high</tt> and <tt>critical</tt>. They have an
effect on how quickly a package will be considered for
inclusion into the <tt>testing</tt> distribution, and
give an indication of the importance of any fixes
included in this upload.
</p>
</footnote>
-->
<var>urgency</var> は、アップロード時の <tt>.changes</tt>
ファイルの <tt>Urgency</tt> フィールドとして使われる値です。
コンマを含む値を使用することはできません。
<prgn>dpkg</prgn> の changelog フォーマットでは、コンマは
<tt><var>keyword</var>=<var>value</var></tt>
の各設定を分離するために使用されています
(しかしながら、現在のところ <var>keyword</var>として有効なものは
<tt>urgency</tt>
<footnote>
<p>
通常、<tt>urgency</tt> のとる値は <tt>low</tt>、<tt>medium</tt>、
<tt>high</tt> と <tt>critical</tt> です。
これはパッケージをどのぐらい急いで <tt>testing</tt>
ディストリビューションに含めないといけないかの判断基準になり、またこのアップロードで含まれている修正の重要性を示唆する効果を持ちます。
</p>
</footnote>
だけです)。
</p>
<p> <!--
The change details may in fact be any series of lines
starting with at least two spaces, but conventionally each
change starts with an asterisk and a separating space and
continuation lines are indented so as to bring them in
line with the start of the text above. Blank lines may be
used here to separate groups of changes, if desired.-->
詳細な変更点は、実際には最低二つのスペースではじまる一連の行に記されていればいいのですが、
慣習的に各変更箇所はアスタリスクと分離のためのスペースで始め、継続行はインデントし、はじめの箇所が分かるような文章にしておきます。
望むのであれば、一連の変更箇所を分離するのに空行が使用できます。
</p>
<p> <!--
If this upload resolves bugs recorded in the Bug Tracking
System (BTS), they may be automatically closed on the
inclusion of this package into the Debian archive by
including the string: <tt>closes: Bug#<var>nnnnn</var></tt>
in the change details.
<footnote>
<p>
To be precise, the string should match the following
Perl regular expression (where $pound=<tt>#</tt>;):
<example>
/closes:\s*(?:bug)?${pound}?\s?\d+(?:,\s*(?:bug)?\${pound}?\s?\d+)*/i
</example>
<footnote>
<p>We had to introduce the $pound variable in the
regexp above because otherwise the utilities
rendering the policy documents gor confused by a
backslashed "#" symbol.
</p>
</footnote>
Then all of the bug numbers listed will be closed by the
archive maintenance script (<prgn>katie</prgn>), or in
the case of an NMU, marked as fixed.
</p>
</footnote>-->
このアップロードがバグトラッキングシステム (BTS)
で記録されたバグを修正するものならば、changelog 中に
<tt>closes: Bug#<var>nnnnn</var></tt>
<footnote>
<p>
より正確には、以下の Perl 正規表現にマッチするような文字列です。ここで $pound=<tt>#</tt>
<footnote>
<p>この正規表現中で $pound 変数を導入しているのは、
ポリシー文書を処理するユーティリティがバックスラッシュつきの
"#" で混乱してうまく処理できないためです。
</p>
</footnote>です。
<example>
/closes:\s*(?:bug)?${pound}?\s?\d+(?:,\s*(?:bug)?\${pound}?\s?\d+)*/i
</example>
列挙されたバグ番号はアーカイブメンテナスクリプト (<prgn>katie</prgn>)
で閉じられるか、NMU の場合には fixed とのマークが付けられます。
</p>
</footnote>
の文字列を含めることで、パッケージが Debian
アーカイブに収録された時点でバグが自動的に閉じられます。
</p>
<p><!--
The maintainer name and email address used in the changelog
should be the details of the person uploading <em>this</em>
version. They are <em>not</em> necessarily those of the
usual package maintainer. The information here will be
copied to the <tt>Changed-By</tt> field in the
<tt>.changes</tt> file, and then later used to send an
acknowledgement when the upload has been installed.
-->
changelog ファイルに記載するメンテナの名前と電子メールアドレスは
<em>この</em> バージョンをアップロードした人について記されているべきです。
必ずしも通常のパッケージ管理者である必要は <em>ありません</em>。
ここでの情報は、<tt>.changes</tt> ファイルの <tt>Changed-By</tt>
フィールドにコピーされ、その後アップロードの完了時に通知を送るために使用します。
</p>
<p>
<!-- The <var>date</var> should be in RFC822 format -->
<var>日付</var> は RFC822 フォーマット
<footnote>
<p><!--
This is generated by the <prgn>822-date</prgn>
program.-->
これは <prgn>822-date</prgn> プログラムで作成します。
</p>
</footnote>
<footnote>
<p> 訳注： RFC2822 参照。</p>
</footnote>
<!--; it should include the time zone specified
numerically, with the time zone name or abbreviation
optionally present as a comment in parentheses.-->
にすべきです。
このフォーマットは、数字によって表現されたタイムゾーンを含むべきで、
オプションとしてかっこに入ったコメントの形でタイムゾーン名かその省略形を付加することができます。
</p>
<p> <!--
The first `title' line with the package name should start
at the left hand margin; the `trailer' line with the
maintainer and date details should be preceded by exactly
one space. The maintainer details and the date must be
separated by exactly two spaces.-->
パッケージ名ではじまる最初の `タイトル' の行は、左詰めにすべきです。
それに続く管理者、日付フィールドの詳細は正確に一つのスペースからはじめるべきです。
管理者の詳細と日付フィールドは、正確に二つのスペースによって区切られていなければいけません。
<!-- ここって「べき」なのかなぁ。元は must みたい -->
</p>
<sect1><heading><!-- Defining alternative changelog formats-->changelog の別書式の定義</heading>
<p> <!--
It is possible to use a different format to the standard
one, by providing a parser for the format you wish to
use.-->
使用したい書式のパーサを用意することで、標準的でない書式を使用することが可能です。
</p>
<p> <!--
A changelog parser must not interact with the user at
all.-->
changelog パーサはユーザとの対話的処理を一切行ってはなりません。
<!-- パッケージングマニュアルからは相当削除あり -->
</p>
</sect1>
</sect>
<sect id="srcsubstvars"><heading><tt>debian/substvars</tt>
<!--and variable substitutions-->と変数置換</heading>
<p> <!--
When <prgn>dpkg-gencontrol</prgn>,
<prgn>dpkg-genchanges</prgn> and <prgn>dpkg-source</prgn>
generate control files they perform variable substitutions
on their output just before writing it. Variable
substitutions have the form
<tt>${<var>variable-name</var>}</tt>. The optional file
<tt>debian/substvars</tt> contains variable substitutions to
be used; variables can also be set directly from
<tt>debian/rules</tt> using the <tt>-V</tt> option to the
source packaging commands, and certain predefined variables
are also available.-->
<prgn>dpkg-gencontrol</prgn>、<prgn>dpkg-genchanges</prgn> 及び
<prgn>dpkg-source</prgn> がコントロールファイルを生成するとき、
出力に書きこむ前に変数置換を行います。
変数置換は <tt>${<var>変数名</var>}</tt> の書式を持ちます。
オプションであるファイルの <tt>debian/substvars</tt>
中に使用する変数置換定義を記載します。
また、変数置換はソースをパッケージするコマンドに <tt>-V</tt>
オプションを指定することによって、直接 <tt>debian/rules</tt>
から設定することもでき、同時に先行定義されている変数が使用できることを確認することもできます。
</p>
<p> <!--
The <tt>debian/substvars</tt> file is usually generated and
modified dynamically by <tt>debian/rules</tt> targets; in
this case it must be removed by the <prgn>clean</prgn>
target.-->
<tt>debian/substvars</tt> ファイルは通常 <tt>debian/rules</tt>
ターゲットによって生成され、動的に変更されます。
このようなやり方を採った場合には
<prgn>clean</prgn> ターゲットによって削除しておかなければいけません。
</p>
<p><!--
See <manref name="dpkg-source" section="1"> for full
details about source variable substitutions, including the
format of <tt>debian/substvars</tt>.-->
<tt>debian/substvars</tt> のフォーマットを含んだソースの変数置換の詳細については、<manref name="dpkg-source" section="1"> をご覧ください。
</p>
</sect>
<sect id="debianfiles"><heading><tt>debian/files</tt>
</heading>
<p> <!--
This file is not a permanent part of the source tree; it
is used while building packages to record which files are
being generated. <prgn>dpkg-genchanges</prgn> uses it
when it generates a <tt>.changes</tt> file.-->
このファイルは、ソースツリーの恒常的な部分ではありません。
これはパッケージをビルドする途中、どのファイルが生成されたのかを記録するのに用いられます。
<prgn>dpkg-genchanges</prgn> は、<tt>.changes</tt> ファイルを生成するときにこれを用います。
</p>
<p> <!--
It should not exist in a shipped source package, and so it
(and any backup files or temporary files such as
<tt>files.new</tt>-->
これはアップロードされるソースパッケージに含めるべきではありません。
そして、それら (およびすべてのバックアップファイルと一時ファイル、例えば、<tt>files.new</tt>
<footnote>
<p><!--
<tt>files.new</tt> is used as a temporary file by
<prgn>dpkg-gencontrol</prgn> and
<prgn>dpkg-distaddfile</prgn> - they write a new
version of <tt>files</tt> here before renaming it,
to avoid leaving a corrupted copy if an error
occurs-->
<tt>files.new</tt> は <prgn>dpkg-gencontrol</prgn> と <prgn>dpkg-distaddfile</prgn> が一時的なファイルとして使います。
エラーが起こったときに壊れたファイルをそのまま残しておかないようにするため、新しいバージョンの <tt>files</tt>
を一旦このファイルに書き出し、その後でファイル名を変えます。
</p>
</footnote><!-- ) should be removed by the
<prgn>clean</prgn> target. It may also be wise to
ensure a fresh start by emptying or removing it at the
start of the <prgn>binary</prgn> target.-->
) は、<prgn>clean</prgn> ターゲットによって削除すべきです。また、
<prgn>binary</prgn> ターゲットのスタート時には、これらのファイルを、
削除するか空にして新しいスタートを確認することはよいやり方です。
</p>
<p> <!--
When <prgn>dpkg-gencontrol</prgn> is run for a binary
package, it adds an entry to <tt>debian/files</tt> for the
<tt>.deb</tt> file that will be created when <prgn>dpkg-deb
--build</prgn> is run for that binary package. So for most
packages all that needs to be done with this file is to
delete it in the <prgn>clean</prgn> target.-->
<prgn>dpkg-gencontrol</prgn>
をバイナリパッケージのため実行した際に、これは
<prgn>dpkg-deb --build</prgn>
をバイナリパッケージ作成のため実行した場合に作成される <tt>.deb</tt>
のためのエントリを <tt>debian/files</tt> に追加します。
このため、たいていのパッケージが、
このファイルに関してやらなければいけないことは、<prgn>clean</prgn>
ターゲットによって削除することだけです。
</p>
<p> <!--
If a package upload includes files besides the source
package and any binary packages whose control files were
made with <prgn>dpkg-gencontrol</prgn> then they should be
placed in the parent of the package's top-level directory
and <prgn>dpkg-distaddfile</prgn> should be called to add
the file to the list in <tt>debian/files</tt>.-->
アップロードされたパッケージが、ソースパッケージとすべてのバイナリパッケージ、
<prgn>dpkg-gencontrol</prgn>
によって生成されたそれらのコントロールファイル以外のファイルを含んでいるときは、
それらのファイルはパッケージのトップ階層ディレクトリの親ディレクトリに置かれるべきです。
そして、<tt>debian/files</tt> のリストにファイルを追加するために
<prgn>dpkg-distaddfile</prgn> を呼ぶようにすべきです。
</sect>
<sect id="restrictions"><heading><!--Restrictions on objects in source packages-->ソースパッケージに含まれるものに対する制限
</heading>
<p> <!--
The source package may not contain any hard links-->
ソースパッケージには、ハードリンク
<footnote>
<p><!--
This is not currently detected when building source
packages, but only when extracting
them.-->
現在、ソースパッケージのビルド中にハードリンクは検出されず、
ソースパッケージの展開時にのみ検出されます。
</p>
<p><!--
Hard links may be permitted at some point in the
future, but would require a fair amount of
work.-->
将来、ハードリンクが許されるようになるかもしれませんが、
それにはまだ多くの作業が必要となります。
</p>
</footnote><!--, device special files, sockets or setuid or
setgid files.-->
、デバイスファイル、ソケットファイル、及び setuid や setgid
されたファイル
<footnote>
<p>
<!--Setgid directories are allowed.-->
setgid されたディレクトリーは許されます。
</p>
</footnote>
が含まれていてはいけません。
</p>
</sect>
<sect id="descriptions"><heading><!--Descriptions of packages - the <tt>Description</tt> field-->
パッケージの説明 - <tt>Description</tt> フィールド </heading>
<p> <!--
The description is intended to describe the program to a user
who has never met it before so that they know whether they
want to install it. It should also give information about the
significant dependencies and conflicts between this package
and others, so that the user knows why these dependencies and
conflicts have been declared.-->
説明文 (description) フィールドの内容は、プログラムに関する説明であり
それまで使用したことのないプログラムをインストールするかどうかの
判断を助けることをねらったものです。パッケージ間の重要な依存関係
(dependency) や競合関係 (conflict) の情報も示されているべきです。
そうでないと、ユーザにはなぜ競合関係や依存関係の不具合が起きているのかが分かりません。
</p>
<sect1><heading><!--Notes about writing descriptions-->
説明文を書く際の留意点
</heading>
<p> <!--
The single line synopsis should be kept brief - certainly
under 80 characters. -->
一行による要約は簡潔にすべきです。半角換算で 80 文字以下としてください。
</p>
<p> <!--
Do not include the package name in the synopsis line. The
display software knows how to display this already, and you
do not need to state it. Remember that in many situations
the user may only see the synopsis line - make it as
informative as you can.-->
パッケージ名を要約 (Synopsis) の行に入れないでください。
入れなくても、表示ソフトウェアはパッケージ名を自動的に表示するようになっています。
多くの場合、ユーザの目に ふれるのはこの要約行だけなので、なるべく分かりやすい要約にするようにしてください。
</p>
<p> <!--
Do not try to continue the single line synopsis into the
extended description. This will not work correctly when
the full description is displayed, and makes no sense
where only the summary (the single line synopsis) is
available.-->
上記の一行要約からそのまま引き続いて説明文に続ける形を取らないでください。
これは説明文の全体が表示されている時にうまくいきませんし、
また要約 (一行の) のみが表示されているときには意味をなしません。
</p>
<p> <!--
The extended description should describe what the package
does and how it relates to the rest of the system (in terms
of, for example, which subsystem it is which part of).-->
詳細の解説部分はそのパッケージ自体の説明、(例えば、このパッケージが
Debian システム全体の中の、どの部分集合に属しているのか)
について記します。
</p>
<p> <!--
The description field needs to make sense to anyone, even
people who have no idea about any of the things the
package deals with.-->
説明文は誰でも、例えばそのパッケージが扱っている分野のことを何も知らない人でも理解できるように
<footnote>
<p><!--
The blurb that comes with a program in its
announcements and/or <prgn>README</prgn> files is
rarely suitable for use in a description. It is
usually aimed at people who are already in the
community where the package is used.-->
そのプログラムにもともと付いているアナウンスや
<prgn>README</prgn> をそのままこの説明文に使用可能な
ことはほとんどありません。通常これらの文章は
そのソフトウェアがどの場面で使われているのかすでに知っている
ユーザコミュニティ向けに書かれています。
</p>
</footnote>
書かなければいけません。
</p>
<p> <!--
Put important information first, both in the synopsis and
extended description. Sometimes only the first part of the
synopsis or of the description will be displayed. You can
assume that there will usually be a way to see the whole
extended description.-->
要約行および詳細の解説部分、これら両者において重要な情報を最初に持ってきてください。
実際の表示時に、要約行または詳細の解説部分の一部しか表示されないことがあるためです。
もっともそういう場合には、詳細の解説部分全体を表示することができるようになっていることを期待するのはかまいません。
</p>
<p> <!--
You may include information about dependencies and so forth
in the extended description, if you wish.-->
もし望むならば、依存関係などの情報も説明文中に含ませることができます。
</p>
<p> <!--
Do not use tab characters. Their effect is not predictable.-->
タブは使用しないでください。どういう動作をするか分かりません。
</p>
</sect1>
</sect>
</chapt>
<!-- <chapt id="maintainerscripts"><heading>Package maintainer scripts
and installation procedure
</heading>-->
<chapt id="maintainerscripts"><heading><!--Package maintainer scripts
and installation procedure-->パッケージ管理スクリプトとインストールの手順
</heading>
<sect><heading><!--Introduction to package maintainer scripts-->パッケージ管理スクリプトへの手引き
</heading>
<p> <!--
It is possible to supply scripts as part of a package which
the package management system will run for you when your
package is installed, upgraded or removed.-->
パッケージをインストール、アップグレード、削除する際に、パッケージ管理システムが走らせるスクリプトをパッケージの一部として供給することが可能です。
</p>
<p> <!--
These scripts are the files <tt>preinst</tt>,
<tt>postinst</tt>, <tt>prerm</tt> and <tt>postrm</tt> in the
control area of the package. They must be proper executable
files; if they are scripts (which is recommended), they must
start with the usual <tt>#!</tt> convention. They should be
readable and executable by anyone, and not world-writable.-->
これらのスクリプトはパッケージの制御エリア内にある <tt>preinst</tt>、
<tt>postinst</tt>、<tt>prerm</tt>、<tt>postrm</tt>
というファイルです。
これらは適正な実行可能ファイルでなくてはなりません。
もし、これらがスクリプト (スクリプトであることを推奨します) ならば、
通常行われているように <tt>#!</tt> で始めなくてはなりません。
これらのスクリプトは誰でも読むことが可能、かつ実行可能で、誰からでも書き込み可能ではないようにすべきです。
</p>
<p> <!--
The package management system looks at the exit status from
these scripts. It is important that they exit with a
non-zero status if there is an error, so that the package
management system can stop its processing. For shell
scripts this means that you <em>almost always</em> need to
use <tt>set -e</tt> (this is usually true when writing shell
scripts, in fact). It is also important, of course, that
they don't exit with a non-zero status if everything went
well.-->
パッケージ管理システムはこれらのスクリプトからの終了ステータスを見ます。
パッケージ管理システムが手続きを止められるように、
エラーがあった場合にはスクリプトが 0
でないステータスで終了するようにしておくことが重要です。
シェルスクリプトでは <em>ほとんど常に</em> <tt>set -e</tt>
を使う必要があるということを意味します (実際には、
通常シェルスクリプトを書く場合は一般に、このようにします)。
もちろん、全てがうまくいった場合に、0 でないステータスで終了しないことも重要です。
</p>
<p> <!--
When a package is upgraded a combination of the scripts from
the old and new packages is called during the upgrade
procedure. If your scripts are going to be at all
complicated you need to be aware of this, and may need to
check the arguments to your scripts.-->
パッケージがアップグレードされる時には、アップグレード手続きの間に古いパッケージと新しいパッケージのスクリプトが、組み合わせて呼び出されます。
もし、あなたのスクリプトがとても複雑になっていく場合には、このことに注意し、スクリプトの引数のチェックが必要になるでしょう。
</p>
<p> <!--
Broadly speaking the <prgn>preinst</prgn> is called before
(a particular version of) a package is installed, and the
<prgn>postinst</prgn> afterwards; the <prgn>prerm</prgn>
before (a version of) a package is removed and the
<prgn>postrm</prgn> afterwards. -->
大まかに言えば、<prgn>preinst</prgn> は (ある特定のバージョンの)
パッケージがインストールされる前に、<prgn>postinst</prgn>
はインストールされた後に呼び出されます。<prgn>prerm</prgn>
はは (あるバージョンの) パッケージが 削除される前に、
<prgn>postrm</prgn> は削除された後に呼び出されます。
</p>
<p> <!--
Programs called from maintainer scripts should not normally
have a path prepended to them. Before installation is
started, the package management system checks to see if the
programs <prgn>ldconfig</prgn>,
<prgn>start-stop-daemon</prgn>, <prgn>install-info</prgn>,
and <prgn>update-rc.d</prgn> can be found via the
<tt>PATH</tt> environment variable. Those programs, and any
other program that one would expect to be on the
<tt>PATH</tt>, should thus be invoked without an absolute
pathname. Maintainer scripts should also not reset the
<tt>PATH</tt>, though they might choose to modify it by
prepending or appending package-specific directories. These
considerations really apply to all shell scripts.-->
管理スクリプトから呼ばれるプログラムは、通常そのスクリプトにおいてプログラムの前にパスをつけて呼び出すべきではありません。
インストールが始まる前に、パッケージ管理システムは
<prgn>ldconfig</prgn>、<prgn>start-stop-daemon</prgn>、
<prgn>install-info</prgn> や <prgn>update-rc.d</prgn>
などのプログラムが指定された <tt>PATH</tt>
環境変数から発見できるかどうかをチェックします。
ですから、これらのプログラムや、<tt>PATH</tt>
にあることを期待してもいいようなプログラムについては、絶対パス名をつけずに呼び出すべきです。
管理スクリプトは <tt>PATH</tt> をリセットすべきではありませんが、
<tt>PATH</tt> の前か後に、パッケージに対して特別なディレクトリを付け加えるという方法を採るのはかまいません。
このような考慮は、実際には、全てのシェルスクリプトに対して当てはまるものです。
</p>
</sect>
<sect>
<heading><!-- Maintainer scripts Idempotency-->メンテナスクリプトの再入結果の同一性</heading>
<p>
<!-- It is very important to make maintainer scripts
idempotent.-->
メンテナスクリプトが再入結果の同一性をもつようにすることはとても重要です。
<p> <!--
It is necessary for the error recovery procedures that the
scripts be idempotent: i.e., invoking the same script several
times in the same situation should do no harm. If the first
call failed, or aborted half way through for some reason,
the second call should merely do the things that were left
undone the first time, if any, and exit with a success
status.-->
エラー回復手続きをできるようにするため、スクリプトは同じ状況にあるときに、それを何度か起動しても無害でなければなりません。
もし、一回目の呼び出しが失敗した、または何らかの理由によって途中で中止した場合、二回目の呼び出しでは一回目で実行し残したものを単に実行し、成功ステータスで終了するようにすべき
<footnote>
<p><!--
This is so that if an error occurs, the user interrupts
<prgn>dpkg</prgn> or some other unforeseen circumstance
happens you don't leave the user with a badly-broken
package when <prgn>dpkg</prgn> attempts to repeat the
action.-->
これがそうあるべきなのは、ユーザからの <prgn>dpkg</prgn>
への割り込みや、他の予測できない状況が発生した際に
<prgn>dpkg</prgn> が処理を再実行しようとした場合、ひどく壊れたパッケージを残さないようにするためです。
</p>
</footnote>
です。
</p>
</sect>
<sect>
<heading><!-- Controlling terminal for maintainer scripts-->メンテナスクリプトからのターミナルの制御</heading>
<p><!--
The maintainer scripts are guaranteed to run with a
controlling terminal and can interact with the user.
If they need to prompt for passwords, do full-screen
interaction or something similar you should do these
things to and from <tt>/dev/tty</tt>, since
<prgn>dpkg</prgn> will at some point redirect scripts'
standard input and output so that it can log the
installation process. Likewise, because these scripts
may be executed with standard output redirected into a
pipe for logging purposes, Perl scripts should set
unbuffered output by setting <tt>$|=1</tt> so that the
output is printed immediately rather than being
buffered.-->
メンテナスクリプトは制御ターミナルがある状態で実行されており、ユーザとの対話ができることが保証されています。
パスワードの入力を求めたり、全画面を使った対話などを行いたい場合には
<tt>/dev/tty</tt> を介して行うべきです。これは <prgn>dpkg</prgn>
がある時点ではスクリプトの標準入出力をリダイレクトしてインストール作業のログを採っていることがあるためです。
同様に、スクリプトがログ採取の目的のため標準出力をパイプでリダイレクトしている場合があるため、Perl
スクリプトでは出力がバッファされず直接出力されるように
<tt>$|=1</tt> と設定してバッファなし出力モードにすべきです。
</p>
<p><!--
Each script should return a zero exit status for
success, or a nonzero one for failure.-->
各スクリプトは成功の場合には終了ステータスを 0 に、失敗の場合には
0 でない値にして帰ってください。
</p>
</sect>
<sect id="mscriptsinstact"><heading><!-- Summary of ways maintainer
scripts are called-->
メンテナスクリプトの呼ばれ方のまとめ
</heading>
<p>
<list compact="compact">
<item>
<p><var>new-preinst</var> <tt>install</tt></p>
</item>
<item>
<p><var>new-preinst</var> <tt>install</tt>
<var>old-version</var></p>
</item>
<item>
<p><var>new-preinst</var> <tt>upgrade</tt>
<var>old-version</var></p>
</item>
<item>
<p><var>old-preinst</var> <tt>abort-upgrade</tt>
<var>new-version</var>
</p>
</item>
</list>
<p>
<list compact="compact">
<item>
<p><var>postinst</var> <tt>configure</tt>
<var>most-recently-configured-version</var></p>
</item>
<item>
<p><var>old-postinst</var> <tt>abort-upgrade</tt>
<var>new-version</var></p>
</item>
<item>
<p><var>conflictor's-postinst</var> <tt>abort-remove</tt>
<tt>in-favour</tt> <var>package</var>
<var>new-version</var></p>
</item>
<item>
<p>
<var>deconfigured's-postinst</var>
<tt>abort-deconfigure</tt> <tt>in-favour</tt>
<var>failed-install-package</var> <var>version</var>
<tt>removing</tt> <var>conflicting-package</var>
<var>version</var>
</p>
</item>
</list>
<p>
<list compact="compact">
<item>
<p><var>prerm</var> <tt>remove</tt></p>
</item>
<item>
<p><var>old-prerm</var> <tt>upgrade</tt>
<var>new-version</var></p>
</item>
<item>
<p><var>new-prerm</var> <tt>failed-upgrade</tt>
<var>old-version</var></p>
</item>
<item>
<p><var>conflictor's-prerm</var> <tt>remove</tt>
<tt>in-favour</tt> <var>package</var>
<var>new-version</var></p>
</item>
<item>
<p>
<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
<tt>in-favour</tt> <var>package-being-installed</var>
<var>version</var> <tt>removing</tt>
<var>conflicting-package</var>
<var>version</var>
</p>
</item>
</list>
<p>
<list compact="compact">
<item>
<p><var>postrm</var> <tt>remove</tt></p>
</item>
<item>
<p><var>postrm</var> <tt>purge</tt></p>
</item>
<item>
<p>
<var>old-postrm</var> <tt>upgrade</tt>
<var>new-version</var></p>
</item>
<item>
<p><var>new-postrm</var> <tt>failed-upgrade</tt>
<var>old-version</var></p>
</item>
<item>
<p><var>new-postrm</var> <tt>abort-install</tt></p>
</item>
<item>
<p><var>new-postrm</var> <tt>abort-install</tt>
<var>old-version</var></p>
</item>
<item>
<p><var>new-postrm</var> <tt>abort-upgrade</tt>
<var>old-version</var></p>
</item>
<item>
<p>
<var>disappearer's-postrm</var> <tt>disappear</tt>
<var>overwriter</var>
<var>overwriter-version</var></p></item>
</list>
</p>
<sect id="unpackphase"><heading><!-- Details of unpack phase of
installation or upgrade-->
インストール時とアップグレート時のパッケージの展開段階の詳細
</heading>
<p> <!--
The procedure on installation/upgrade/overwrite/disappear
(i.e., when running <tt>dpkg --unpack</tt>, or the unpack
stage of <tt>dpkg --install</tt>) is as follows. In each
case, if a major error occurs (unless listed below) the
actions are, in general, run backwards - this means that the
maintainer scripts are run with different arguments in
reverse order. These are the `error unwind' calls listed
below.-->
インストール／アップグレード／上書き／消去 (すなわち、
<tt>dpkg --unpack</tt> が走っているとき、または
<tt>dpkg --install</tt> の展開段階のとき)
の手続きは下記の通りになります。どのような場合においても、
もしエラーが起これば (下記の場合を除けば) そこでの動作は、一般に逆方向へ走る処理です。
これは、管理スクリプトが異なる引数で逆順に走らされるということです。
このような呼び出しは以降の説明では「エラー回復」呼び出しとして記しています。
<enumlist>
<item>
<p>
<enumlist>
<item>
<p><!-- If a version of the package is already
installed, call-->
対象となるパッケージの、あるバージョンが既に
インストールされている場合は次の呼び出しをします。
<example>
<var>old-prerm</var> upgrade <var>new-version</var>
</example></p>
</item>
<item>
<p><!--
If the script runs but exits with a non-zero
exit status, <prgn>dpkg</prgn> will attempt:-->
もし、これがエラーとなったら (つまり、
ゼロでない終了ステータスであったら)、
<prgn>dpkg</prgn> はかわりに次の呼び出しをします。
<example>
<var>new-prerm</var> failed-upgrade <var>old-version</var>
</example>
<!-- Error unwind, for both the above cases:-->
上の両方の場合におけるエラー回復は、次の通りです。
<example>
<var>old-postinst</var> abort-upgrade <var>new-version</var>
</example>
</p>
</item>
</enumlist>
</p>
</item>
<item>
<p><!-- If a `conflicting' package is being removed at the same time:-->
「衝突する」パッケージが同時に削除される場合には
<enumlist>
<item>
<p><!--
If any packages depended on that conflicting
package and <tt>--auto-deconfigure</tt> is
specified, call, for each such package:-->
もし、その衝突するパッケージに依存するパッケージがあり、
<tt>--auto-deconfigure</tt> が指定されているならば、
該当の各パッケージについて、次の呼び出しを行います。
<example>
<var>deconfigured's-prerm</var> deconfigure \
in-favour <var>package-being-installed</var> <var>version</var> \
removing <var>conflicting-package</var> <var>version</var>
</example>
<!-- Error unwind:-->このときのエラー回復は
<example>
<var>deconfigured's-postinst</var> abort-deconfigure \
in-favour <var>package-being-installed-but-failed</var> <var>version</var> \
removing <var>conflicting-package</var> <var>version</var>
</example>
<!-- The deconfigured packages are marked as
requiring configuration, so that if
<tt>--install</tt> is used they will be
configured again if possible.-->
です。もし、<tt>--install</tt> が使われたばあいに再設定可能としておくため、
設定破棄されたパッケージには設定を要求するマークが付けられます。
</p>
</item>
<item>
<p><!-- To prepare for removal of the conflicting package, call:-->
衝突しているパッケージを削除するための準備として、次の呼び出しが行われます。
<example>
<var>conflictor's-prerm</var> remove in-favour <var>package</var> <var>new-version</var>
</example>
<!-- Error unwind:-->このときのエラー回復は
<example>
<var>conflictor's-postinst</var> abort-remove \
in-favour <var>package</var> <var>new-version</var>
</example>
です。
</p>
</item>
</enumlist>
</p>
</item>
<item>
<p>
<enumlist>
<item>
<p><!-- If the package is being upgraded, call:-->
パッケージがアップグレードされる場合には、次の呼び出しが行われます。
<example>
<var>new-preinst</var> upgrade <var>old-version</var>
</example></p>
</item>
<item>
<p><!--
Otherwise, if the package had some configuration
files from a previous version installed (i.e., it
is in the `configuration files only' state):-->
そうではない場合、もしそのパッケージの以前のバージョンからの設定ファイルがあった
(すなわち「設定ファイルのみ」の状態にあった)
ならば、次の呼び出しが行われます。
<example>
<var>new-preinst</var> install <var>old-version</var>
</example></p>
<item>
<p><!-- Otherwise (i.e., the package was completely purged):-->
そうでもない (つまり、そのパッケージが完全削除されていた)
場合、次の呼び出しが行われます。
<example>
<var>new-preinst</var> install
</example>
<!-- Error unwind actions, respectively:-->
このときのエラー回復は、順に
<example>
<var>new-postrm</var> abort-upgrade <var>old-version</var>
<var>new-postrm</var> abort-install <var>old-version</var>
<var>new-postrm</var> abort-install
</example>
です。
</p>
</item>
</enumlist>
</p>
</item>
<item>
<p><!--
The new package's files are unpacked, overwriting any
that may be on the system already, for example any
from the old version of the same package or from
another package. Backups of the old files are kept
temporarily, and if anything goes wrong the package
management system will attempt to put them back as
part of the error unwind.-->
新しいパッケージのファイルが展開され、システムに既にあるファイル、例えば同じパッケージの古いバージョンからのファイルや、
他のパッケージからのファイルに上書きされます
古いファイルのバックアップが一時的に保持され、もし何か問題が起こればパッケージ管理システムがエラー回復の一部としてそれらを元に戻そうとします。
</p>
<p> <!--
It is an error for a package to contains files which
are on the system in another package, unless
<tt>Replaces</tt> is used (see <ref id="replaces">).
<!--
The following paragraph is not currently the case:
Currently the <tt>--force-overwrite</tt> flag is
enabled, downgrading it to a warning, but this may not
always be the case.-->
あるパッケージが、現在システムにある別のパッケージの
ファイルと同名のファイルを含んでいる場合、<tt>Replaces</tt>
(<ref id="replaces"> 参照)
が指定されていない場合にはエラーになります。
<!--
以下は既に正しくありません：
現在のところ
<tt>--force-overwrite</tt> フラグが有効にされており、このエラーは警告に格下げされています。
但し、将来にわたってもこうであるわけではありません。-->
</p>
<p> <!--
It is a more serious error for a package to contain a
plain file or other kind of non-directory where another
package has a directory (again, unless
<tt>Replaces</tt> is used). This error can be
overridden if desired using
<tt>--force-overwrite-dir</tt>, but this is not
advisable.-->
パッケージにとってもっと深刻なエラーとなるのは、他のパッケージからのディレクトリがある場所に
そのパッケージが普通のファイルやほかのディレクトリでないような内容物を含んでいた場合です (ここでも、<tt>Replaces</tt>
が使われていない場合においてです)。もし望むなら、
<tt>--force-overwrite-dir</tt> を使ってこのエラーを無効にすることができますが、これは勧められません。
</p>
<p> <!--
Packages which overwrite each other's files produce
behavior which, though deterministic is hard for the
system administrator to understand. It can easily
lead to `missing' programs if, for example, a package
is installed which overwrites a file from another
package, and is then removed again.-->
お互いのファイルに上書きするパッケージは、決定論的に決まるのではあるけれども、システム管理者には理解しがたい振る舞いをします。
この状態では、簡単にプログラムを「見失う」事態が起こり得ます。
例えば、他のパッケージからのファイルに上書きするようなパッケージをインストールして、それから、そのパッケージを削除することでこのような
「見失い」
<footnote>
<p><!--
Part of the problem is due to what is arguably a
bug in <prgn>dpkg</prgn>.-->
問題のうちの一部は、おそらく、<prgn>dpkg</prgn>
のバグとされている挙動のためです。
</p>
</footnote> が起こります。
</p>
<p> <!--
A directory will never be replaced by a symbolic link
to a directory or vice versa; instead, the existing
state (symlink or not) will be left alone and
<prgn>dpkg</prgn> will follow the symlink if there is
one.-->
ディレクトリは、決してディレクトリへのシンボリックリンクに置き換わってしまうことはありませんし、その逆もありません。
そのかわりに、現在ある状態 (シンボリックリンクであるのか否か)
はそのままにされて、シンボリックリンクの場合 <prgn>dpkg</prgn>
はそのリンクをたどります。</p>
</item>
<item>
<p><enumlist>
<item>
<p><!-- If the package is being upgraded, call-->
もし、パッケージがアップグレードされている最中なら、次の呼び出しを行います。
<example>
<var>old-postrm</var> upgrade <var>new-version</var>
</example></p>
</item>
<item>
<p><!-- If this fails, <prgn>dpkg</prgn> will attempt:-->
もしこれに失敗したら、<prgn>dpkg</prgn> は次の呼び出しを試みます。
<example>
<var>new-postrm</var> failed-upgrade <var>old-version</var>
</example>
<!-- Error unwind, for both cases:-->
上の両方の場合におけるエラー回復は
<example>
<var>old-preinst</var> abort-upgrade <var>new-version</var>
</example>
です。
</p>
</item>
</enumlist>
<p><!--
This is the point of no return - if
<prgn>dpkg</prgn> gets this far, it won't back off
past this point if an error occurs. This will
leave the package in a fairly bad state, which
will require a successful re-installation to clear
up, but it's when <prgn>dpkg</prgn> starts doing
things that are irreversible.-->
ここが戻れなくなるポイントです。<prgn>dpkg</prgn>
がさらに先に進むと、エラーがあった場合にもこのポイントより前には戻りません。
この場合、パッケージが非常に悪い状態で残り、
これをきれいにするためには、再インストールを成功させる必要があります。
ですが、ここが <prgn>dpkg</prgn> は戻ることのできない作業を始める時です。
</p>
</item>
<item>
<p> <!--
Any files which were in the old version of the package
but not in the new are removed.-->
古いバージョンのパッケージにはあって、新しいものには無いファイルは削除されます。</p>
</item>
<item>
<p><!-- The new file list replaces the old.-->
ファイルリストが、古いものから新しいものに置き換えられます。</p>
</item>
<item>
<p><!-- The new maintainer scripts replace the old.-->
新しいメンテナスクリプトで、古いものを置き換えます。</p>
</item>
<item>
<p><!--
Any packages all of whose files have been overwritten during the
installation, and which aren't required for
dependencies, are considered to have been removed.
For each such package-->
あるパッケージに属するファイルが、インストールの間に全て上書きされ、依存の要求も無いような場合、そのパッケージは削除されたと見なします。
そのようなパッケージそれぞれに対して、
<enumlist>
<item>
<p><prgn>dpkg</prgn> <!-- calls:-->は次の呼び出しを行います。
<example>
<var>disappearer's-postrm</var> disappear \
<var>overwriter</var> <var>overwriter-version</var>
</example>
</p>
</item>
<item>
<p><!-- The package's maintainer scripts are removed.-->
パッケージ管理スクリプトが削除されます。
</p>
</item>
<item>
<p><!--
It is noted in the status database as being in a
sane state, namely not installed (any conffiles
it may have are ignored, rather than being
removed by <prgn>dpkg</prgn>). Note that
disappearing packages do not have their prerm
called, because <prgn>dpkg</prgn> doesn't know
in advance that the package is going to
vanish.-->
パッケージ状態のデータベースには、正常な状態、つまりインストールされていないものとして記録されます
(そのパッケージが持っていた設定ファイルがあれば、それは
<prgn>dpkg</prgn> によって削除されるのではなく、無視されます)。
<prgn>dpkg</prgn> は前もって、そのパッケージが削除されそうなのかどうかを知らないので、
削除されるパッケージの `prerm' は 呼び出されないということに注意してください。
</p>
</item>
</enumlist>
</p>
</item>
<item>
<p><!--
Any files in the package we're unpacking that are also
listed in the file lists of other packages are removed
from those lists. (This will lobotomize the file list
of the `conflicting' package if there is one.)-->
展開しようとしているパッケージの中にあって、他のパッケージのファイルリストにも記されている全てのファイルは、これらのリストから削除されます
(これにより、もし「衝突する」パッケージがあれば、その衝突するパッケージのファイルリストが修正されます)。
</p>
</item>
<item>
<p><!--
The backup files made during installation, above, are
deleted.-->
今までのインストール作業の中で作成されていたバックアップファイルを消去します。
</p>
</item>
<item>
<p><!--
The new package's status is now sane, and recorded as
`unpacked'.-->
新しいパッケージの状態は、今では正常になっていますので、「展開」として記録されます。
</p>
<p> <!--
Here is another point of no return - if
the conflicting package's removal fails we do not
unwind the rest of the installation; the conflicting
package is left in a half-removed limbo.-->
ここが次の戻れなくなるポイントです。
もし衝突するパッケージの削除に失敗したばあいでも、これから後のインストール作業を戻すようなことはしません。
衝突したパッケージは半分削除された亡霊状態で残ってしまいます。
</p>
</item>
<item>
<p><!--
If there was a conflicting package we go and do the
removal actions (described below), starting with the
removal of the conflicting package's files (any that
are also in the package being installed have already
been removed from the conflicting package's file list,
and so do not get removed now).-->
もし衝突するパッケージがあれば、次項に記載の削除作業へ移り、実行します。
削除作業は衝突するパッケージのファイルを削除することから始まります
(インストールされたパッケージの中にもあるファイルは、すでに衝突するパッケージのファイルリストから削除されているので、
この際に削除されてしまうことはありません)。
</p>
</item>
</enumlist>
</p>
</sect>
<sect><heading><!-- Details of configuration-->設定の詳細</heading>
<p>
<!-- When we configure a package (this happens with <tt>dpkg
--install</tt>, or with <tt>--configure</tt>), we first
update any <tt>conffile</tt>s and then call: -->
パッケージを設定する (この状況は <tt>dpkg --install</tt> や
<tt>--configure</tt> で起きます) とき、まず <tt>conffile</tt>
を更新し、それから次の呼び出しが行われます。
<example>
<var>postinst</var> configure <var>most-recently-configured-version</var>
</example>
</p>
<p> <!--
No attempt is made to unwind after errors during
configuration.-->
設定中にエラーが起こった後、回復は行われません。
</p>
<p> <!--
If there is no most recently configured version
<prgn>dpkg</prgn> will pass a null argument; older versions
of dpkg may pass <tt><unknown></tt> (including the
angle brackets) in this case. Even older ones do not pass a
second argument at all, under any circumstances.-->
もし最近設定されたバージョン (上の呼び出しの
<var>most-recently-configured-version</var>) が存在しなければ、
<prgn>dpkg</prgn> は引数にとして何も渡しません。
古いバージョンの <prgn>dpkg</prgn> は <tt><unknown></tt>
を (不等号も含めて) 渡すかもしれません。さらに古いバージョンの
<prgn>dpkg</prgn> は、どのような状況においても二番目の引数は何も渡しません。
</p>
</sect>
<sect><heading><!--Details of removal and/or configuration purging-->
削除と設定の完全削除の詳細
</heading>
<p>
<enumlist>
<item>
<p>
<example>
<var>prerm</var> remove
</example>
</p>
</item>
<item>
<p><!--
The package's files are removed (except <tt>conffile</tt>s).-->
パッケージのファイルを (<tt>conffile</tt> 群を除いて) 削除します。
</p>
</item>
<item>
<p><example>
<var>postrm</var> remove
</example></p>
</item>
<item>
<p><!--
All the maintainer scripts except the <tt>postrm</tt>
are removed.-->
<tt>postrm</tt> 以外のメンテナスクリプトを全て削除します。
</p>
<p> <!--
If we aren't purging the package we stop here. Note
that packages which have no <tt>postrm</tt> and no
<tt>conffile</tt>s are automatically purged when
removed, as there is no difference except for the
<prgn>dpkg</prgn> status.</p> -->
もしパッケージを完全削除しているのでなければ、ここで止まります。
パッケージに <tt>postrm</tt> も <tt>conffile</tt>
もないのであれば、削除 (remove) と完全削除 (purge) には
<prgn>dpkg</prgn> の状態以外に違いが無いので、自動的に完全削除されることに注意してください。
</p>
</item>
<item>
<p><!--
The conffiles and any backup files (<tt>~</tt>-files,
<tt>#*#</tt> files, <tt>%</tt>-files,
<tt>.dpkg-{old,new,tmp}</tt>, etc.) are removed.-->
設定ファイルと全てのバックアップファイル (<tt>~</tt> ファイル、
<tt>#*#</tt> ファイル、<tt>%</tt> ファイル、
<tt>.dpkg-{old,new,tmp}</tt> など) が削除されます。
</p>
</item>
<item>
<p><example>
<var>postrm</var> purge
</example></p>
</item>
<item>
<p><!-- The package's file list is removed.-->
パッケージのファイルリストが削除されます。</p>
</item>
</enumlist><!--
No attempt is made to unwind after errors during
removal.-->
削除中にエラーが起こった後、回復は行われません。</p>
</sect>
</chapt>
<chapt id="relationships"><heading><!-- Declaring relationships between
packages-->パッケージ間の関連性の宣言</heading>
<p> <!--
Packages can declare in their control file that they have
certain relationships to other packages - for example, that
they may not be installed at the same time as certain other
packages, and/or that they depend on the presence of others,
or that they should overwrite files in certain other packages
if present.-->
各パッケージは、そのコントロールファイルの中で、
同時にインストールすることができないパッケージや、
他のパッケージの存在に依存していたり、
特定の他のパッケージが存在している場合そのファイルを上書きするなど、
特定の他パッケージとの関連づけを宣言することができます。
</p>
<p> <!--
This is done using the <tt>Depends</tt>, <tt>Recommends</tt>,
<tt>Suggests</tt>, <tt>Enhances</tt>, <tt>Conflicts</tt>,
<tt>Provides</tt> and <tt>Replaces</tt> control file fields.-->
この宣言には、コントロールファイルの <tt>Depends</tt>、<tt>Recommends</tt>、
<tt>Suggests</tt>、<tt>Enhances</tt>、<tt>Conflicts</tt>、
<tt>Provides</tt> 及び <tt>Replaces</tt> フィールドを使用します。
</p>
<p><!--
Source packages may declare relationships to binary packages,
saying that they require certain binary packages to be
installed or absent at the time of building the package.-->
ソースパッケージは、バイナリパッケージとの関連を宣言しても構いません。
バイナリパッケージとの関連とは、そのパッケージのビルド時に、
あるバイナリパッケージがインストールされている必要があること、
またはシステムに存在してはならないことを示すものです。
</p>
<p><!--
This is done using the <tt>Build-Depends</tt>,
<tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts</tt>, and
<tt>Build-Conflicts-Indep</tt> control file fields.-->
この宣言には、コントロールファイルの <tt>Build-Depends</tt>、
<tt>Build-Depends-Indep</tt>、<tt>Build-Conflicts</tt> 及び
<tt>Build-Conflicts-Indep</tt> フィールドを使用します。
</p>
<sect id="depsyntax"><heading><!-- Syntax of relationship fields-->
関係性フィールドの書式
</heading>
<p> <!--
These fields all have a uniform syntax. They are a list of
package names separated by commas.-->
これらのフィールドは統一的な書式を持ちます。
それはコンマで区切られたパッケージ名のリストです。
</p>
<p><!--
In the <tt>Depends</tt>, <tt>Recommends</tt>,
<tt>Suggests</tt>, <tt>Pre-Depends</tt>,
<tt>Build-Depends</tt> and <tt>Build-Depends-Indep</tt>
control file fields of the package, which declare
dependencies on other packages, the package names listed may
also include lists of alternative package names, separated
by vertical bar symbols <tt>|</tt> (pipe symbols). In such
a case, the presence of any one of the alternative packages
is installed, that part of the dependency is considered to
be satisfied.-->
パッケージの <tt>Depends</tt>、<tt>Recommends</tt>、
<tt>Suggests</tt>、<tt>Pre-Depends</tt>、<tt>Build-Depends</tt> 及び
<tt>Build-Depends-Indep</tt> の各コントロールファイルフィールド
(他のパッケージに依存関係がある場合に宣言するフィールド)
内に記述するパッケージ名は、代替パッケージ名の一覧でも構いません。
代替パッケージ名は、 垂直バーシンボル <tt>|</tt> (パイプシンボル)
で区切って書きます。
</p>
<p> <!--
All the fields except <tt>Provides</tt> may restrict their
applicability to particular versions of each named package.
This is done in parentheses after each individual package
name; the parentheses should contain a relation from the
list below followed by a version number, in the format
described in <ref id="versions">.-->
<tt>Provides</tt> 以外のすべてのフィールドでは、パッケージ名ごとにそのバージョンを指定することができます。
その指定は、各パッケージ名の後に続く括弧の中で行なわれ、その括弧の中には、下記の一覧で示される (バージョン番号の)
関係を表す記号と、それに続いて <ref id="versions">
で記載された書式に従ったバージョン番号を、記述します。
</p>
<p> <!--
The relations allowed are <tt><<</tt>, <tt><=</tt>,
<tt>=</tt>, <tt>>=</tt> and <tt>>></tt> for
strictly earlier, earlier or equal, exactly equal, later or
equal and strictly later, respectively. The forms
<tt><</tt> and <tt>></tt> were used to mean
earlier/later or equal, rather than strictly earlier/later,
so they should not appear in new packages (though
<prgn>dpkg</prgn> still supports them).-->
バージョン番号の関係を示すために使用する記号は、<tt><<</tt>、
<tt><=</tt>、<tt>=</tt>、<tt>>=</tt> 及び <tt>>></tt>
で、順に「より小さい」「以下」「等しい」「以上」「より大きい」
を意味しています。
記号 <tt><</tt> と <tt>></tt> はそれぞれ「以下」「以上」
という意味であって、「より小さい」または「より大きい」
という意味ではありません。新しいパッケージでは、
<tt><</tt> と <tt>></tt> は使うべきではありません
(<prgn>dpkg</prgn> はまだこの書式をサポートしてはいます)。
</p>
<p> <!--
Whitespace may appear at any point in the version
specification, and must appear where it's necessary to
disambiguate; it is not otherwise significant. For
consistency and in case of future changes to
<prgn>dpkg</prgn> it is recommended that a single space be
used after a version relationship and before a version
number; it is usual also to put a single space after each
comma, on either side of each vertical bar, and before each
open parenthesis.-->
空白は、バージョン設定のどの部分に入れてもかまいません。また、
必要ならば空白を挿入してあいまいさを取りのぞかなければいけません。
ただし、空白にそれ以上の意味はありません。
なお、データの一貫性や、将来の <prgn>dpkg</prgn> の変更を見越して、
バージョン関係記号の後ろ、つまりバージョン番号の前に、空白を一ついれることを推奨します。
通常は、コンマのあとに空白を一つ入れ、パイプシンボル「|」
の両側にも空白を入れます。また、開括弧の前にも空白を一つ入れます。
</p>
<p>
<!-- For example:-->例を次に示します。
<example>
Package: metamail
Version: 2.7-3
Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh
</example>
</p>
<p><!--
All fields that specify build-time relationships
(<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
<tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt>)
may be restricted to a certain set of architectures. This
is done in brackets after each individual package name and
the optional version specification. The brackets enclose a
list of Debian architecture names separated by whitespace.
Exclamation marks may be prepended to each of the names.
(It is not permitted for some names to be prepended with
exclamation marks and others not.) If the current Debian
host architecture is not in this list and there are no
exclamation marks in the list, or it is in the list with a
prepended exclamation mark, the package name and the
associated version specification are ignored completely for
the purposes of defining the relationships.
-->
ビルド時のパッケージ間の関連を示す全てのフィールド
(<tt>Build-Depends</tt>、<tt>Build-Depends-Indep</tt>、
<tt>Build-Conflicts</tt> 及び <tt>Build-Conflicts-Indep</tt>)
は、ある特定のアーキテクチャのセットに限定してもかまいません。
これは、それぞれのパッケージ名とオプションのバージョン指定の後に、
角括弧ではさんで指定します。角括弧のなかには、空白で区切られた Debian
アーキテクチャの名前のリストを入れます。感嘆符 (!)
を一つまたは複数の各アーキテクチャ名の前に置くこともできます
(一部の名前に感嘆符を置き、他の名前に置かない、という指定は許されません)。
もし、現在の Debian ホストのアーキテクチャがこのリストに無く、感嘆符のついた指定も無い場合、もしくは感嘆符付きでこのリスト中にある場合には、
そのパッケージ名とバージョン指定はパッケージ間の関連を定義するためには使われず、完全に無視されます。
</p>
<p>
<!-- For example:-->例を次に示します。
<example>
Source: glibc
Build-Depends-Indep: texinfo
Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
hurd-dev [hurd-i386], gnumach-dev [hurd-i386]
</example>
</p>
</sect>
<sect>
<heading><!-- Binary Dependencies - <tt>Depends</tt>,
<tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
<tt>Pre-Depends</tt>-->
バイナリの依存関係 - <tt>Depends</tt>、
<tt>Recommends</tt>、<tt>Suggests</tt>、<tt>Enhances</tt>、
<tt>Pre-Depends</tt>
</heading>
<p> <!--
These five fields are used to declare a dependency
relationship by one package on another. They appear in the
depending package's control file.-->
これらの五つのフィールドはあるパッケージと他のパッケージとの依存関係を宣言するために使用します。
これらのフィールドは、依存する側のパッケージのコントロールファイルの中に記述されます。
</p>
<p> <!--
All but <tt>Pre-Depends</tt> and <tt>Conflicts</tt>
(discussed below) take effect <em>only</em> when a package
is to be configured. They do not prevent a package being on
the system in an unconfigured state while its dependencies
are unsatisfied, and it is possible to replace a package
whose dependencies are satisfied and which is properly
installed with a different version whose dependencies are
not and cannot be satisfied; when this is done the depending
package will be left unconfigured (since attempts to
configure it will give errors) and will not function
properly.-->
<tt>Pre-Depends</tt> と <tt>Conflicts</tt>
(これらについては以降の節で説明します) 以外のすべての宣言は、
パッケージを <em>設定する時にだけ</em> 有効です。依存関係の宣言は、
依存関係を満たさないパッケージが、未設定な状態でシステム中にインストールされることを妨げません。
すでに依存関係が満たされ、正しくインストールされているパッケージを、
依存関係の満たされていない、または満たせ得ないような別のバージョンのパッケージで置き換えることもできます。
この場合は、未設定のまま (設定しようとするとエラーが返りますので)
ですので、当然正しく動作しないでしょう。
</p>
<p> <!--
For this reason packages in an installation run are usually
all unpacked first and all configured later; this gives
later versions of packages with dependencies on later
versions of other packages the opportunity to have their
dependencies satisfied.-->
このため、最初のインストール時にはすべてのパッケージがまず展開されて、その後すべてのパッケージを設定 (configure) します。
こうすることによって、現存のシステムに存在しない、
新しいバージョンのパッケージに依存関係を宣言している新しいパッケージの依存関係を満たすことができます。
</p>
<p> <!--
Thus <tt>Depends</tt> allows package maintainers to impose
an order in which packages should be configured.-->
このように、<tt>Depends</tt> フィールドによって、パッケージのメンテナはパッケージの設定順序を指定できます。
<taglist>
<tag><tt>Depends</tt></tag>
<item>
<p><!-- This declares an absolute dependency.-->
これは、完全に依存するパッケージを宣言します。
</p>
<p> <!--
The <tt>Depends</tt> field should be used if the
depended-on package is required for the depending
package to provide a significant amount of
functionality.-->
<tt>Depends</tt> フィールドは依存する側のパッケージが、
その主要な機能を提供するために依存される側のパッケージが必要になる場合に指定するべきです。
</p>
</item>
<tag><tt>Recommends</tt></tag>
<item>
<p><!-- This declares a strong, but not absolute, dependency.-->
強い依存関係だけれども、絶対というほどではない依存関係の場合に宣言します。
</p>
<p> <!--
The <tt>Recommends</tt> field should list packages
that would be found together with this one in all but
unusual installations.-->
この <tt>Recommends</tt> フィールドには、特別な場合でないかぎり一緒に使用されるパッケージが書かれます。</p>
</item>
<tag><tt>Suggests</tt></tag>
<item>
<p><!--
This is used to declare that one package may be more
useful with one or more others. Using this field
tells the packaging system and the user that the
listed packages are related to this one and can
perhaps enhance its usefulness, but that installing
this one without them is perfectly reasonable.-->
一つまたは複数の他のパッケージが存在するとこのパッケージをより便利に使える場合、この依存関係を宣言します。
このフィールドはパッケージ管理システムとユーザに、
列挙されたパッケージはこのパッケージに関連があり、
おそらくこのパッケージの有用性を増すであろうけれども、
列挙されたパッケージをインストールしなくとも全然問題がないことを教えます。
</p>
</item>
<tag><tt>Enhances</tt></tag>
<item>
<p><!--
This field is similar to Suggests but works in the
opposite direction. It is used to declare that a
package can enhance the functionality of another
package.-->
このフィールドは `Suggests' に似ていますが、逆向きに作用します。
これは、このパッケージがここに列挙されたパッケージの有用性を増すときに指定します。
</p>
</item>
<tag><tt>Pre-Depends</tt></tag>
<item>
<p><!--
This field is like <tt>Depends</tt>, except that it
also forces <prgn>dpkg</prgn> to complete installation
of the packages named before even starting the
installation of the package which declares the
Pre-dependency.-->
このフィールドは <tt>Depends</tt> と似ていますが、この依存関係は目的のパッケージのインストール前に、先行依存 (predependency)
するパッケージの完全インストールを <prgn>dpkg</prgn>
に強制します。
</p>
<p> <!--
<tt>Pre-Depends</tt> should be used sparingly,
preferably only by packages whose premature upgrade or
installation would hamper the ability of the system to
continue with any upgrade that might be in progress.-->
<tt>Pre-Depends</tt> は濫用すべきではなく、
望ましくは対象となるパッケージの不完全な更新やインストールが、
システムで進行中の更新作業を続ける妨げとなる場合のみに使用するようにするべきです。
</p>
<p> <!--
When the package declaring it is being configured, a
<tt>Pre-Dependency</tt> will be considered satisfied
only if the depending package has been correctly
configured, just as if an ordinary <tt>Depends</tt>
had been used.-->
パッケージが設定中の時、<tt>Pre-Dependency</tt>
は依存するパッケージが正常に設定済である場合にのみ満たされていると判断されます。
これは、通常の <tt>Depends</tt> の場合と同じです。
</p>
<p> <!--
However, when a package declaring a Pre-dependency is
being unpacked the predependency can be satisfied even
if the depended-on package(s) are only unpacked or
half-configured, provided that they have been
configured correctly at some point in the past (and
not removed or partially removed since). In this case
both the previously-configured and currently unpacked
or half-configured versions must satisfy any version
clause in the <tt>Pre-Depends</tt> field.-->
ただし、先行依存されているパッケージ (群) が、過去のある時点できちんと設定され、以後削除も部分的削除もされていない場合には、
そのパッケージが現時点で展開中や中途半端に設定されている状態であっても、先行依存関係は満たされます。
この場合は、以前に設定されていたパッケージのバージョンと、現在展開された、またはある程度設定されたバージョンとの両方が、<tt>Pre-Depends</tt>
フィールドのバージョン部分を満たしていなければいけません。
</p>
</item>
</taglist>
</p>
<p> <!--
When selecting which level of dependency to use you should
consider how important the depended-on package is to the
functionality of the one declaring the dependency. Some
packages are composed of components of varying degrees of
importance. Such a package should list using
<tt>Depends</tt> the package(s) which are required by the
more important components. The other components'
requirements may be mentioned as Suggestions or
Recommendations, as appropriate to the components' relative
importance.-->
依存関係のレベルを選択するにあたって、そのパッケージの機能において依存パッケージの機能がどの程度重要なのかを考えるべきです。
あるパッケージが、重要度の異なるいくつかの部品から構成されているとします。そのとき、その各部品のなかでも重要度の高いものが必要とするようなパッケージを
<tt>Depends</tt> として並べ挙げるべきです。
そのほかの部分が必要とするパッケージは、その部品の相対的な重要性にしたがって Suggests なり、Recommends として参照されることになります。
</p>
<sect id="conflicts"><heading><!-- Alternative binary packages -
<tt>Conflicts</tt> and <tt>Replaces</tt>-->
代替バイナリパッケージ - <tt>Conflicts</tt> と <tt>Replaces</tt>
</heading>
<p> <!--
When one binary package declares a conflict with another
<prgn>dpkg</prgn> will refuse to allow them to be installed
on the system at the same time.-->
あるバイナリパッケージが他のパッケージとの競合関係を宣言している場合、<prgn>dpkg</prgn>
は、それら二つのパッケージを同時にインストールすることを拒否します。
</p>
<p> <!--
If one package is to be installed, the other must be removed
first - if the package being installed is marked as
replacing (<ref id="replaces">) the one on the system, or
the one on the system is marked as deselected, or both
packages are marked <tt>Essential</tt>, then
<prgn>dpkg</prgn> will automatically remove the package
which is causing the conflict, otherwise it will halt the
installation of the new package with an error. This
mechanism specifically doesn't work when the installed
package is <tt>Essential</tt>, but the new package is not.-->
このようなパッケージをインストールするには、もう一方のパッケージをまず削除しなければいけません。
実際の動作としては、インストールしようとしているパッケージに、システム上にあるパッケージを置き換える (<ref id="replaces">)
ようにマークが付けられている場合、システムにインストールされているパッケージに選択を解除するようマークが付けられている場合、また両方のパッケージに
<tt>Essential</tt> という宣言がされている場合は、
<prgn>dpkg</prgn> は、競合関係の原因となっているパッケージを自動的に削除します。
そうでない時は、エラーを出力し新規パッケージのインストールを中止します。
特に、インストールされているパッケージが <tt>Essential</tt>
であり、新しくインストールしようとするパッケージがそうでない場合は
このような自動的な削除は行われません。
</p>
<p> <!--
A package will not cause a conflict merely because its
configuration files are still installed; it must be at least
half-installed.-->
あるパッケージは単に設定ファイルがまだインストールされているために競合関係をひきおこすことはありません。
競合関係にあるためには最低でも half-installed の状態でなければいけません。
</p>
<p> <!--
A special exception is made for packages which declare a
conflict with their own package name, or with a virtual
package which they provide (see below): this does not
prevent their installation, and allows a package to conflict
with others providing a replacement for it. You use this
feature when you want the package in question to be the only
package providing something.-->
インストール中のパッケージ自身の名前やそれ自身が提供する仮想パッケージ
(<ref id="virtualpackage"> を参照してください)
との競合関係が宣言されている場合は特殊な例外です。この場合、
そのようなパッケージのインストールが妨げられることはありません。
また、問題のパッケージを置換する他のパッケージと競合させることもできます。
対象のパッケージだけがある特定の機能を提供するように指定したいときに、このような宣言を使用します。
<!-- see below とあるが、仮想パッケージの説明は前 -->
</p>
<p> <!--
A <tt>Conflicts</tt> entry should almost never have an
`earlier than' version clause. This would prevent
<prgn>dpkg</prgn> from upgrading or installing the package
which declared such a conflict until the upgrade or removal
of the conflicted-with package had been completed. -->
<tt>Conflicts</tt> フィールドは、ほとんど常にバージョン番号の指定に「より古い」という指定を含むべきではありません。
このような指定を行うと、<prgn>dpkg</prgn>
は、その競合関係を宣言しているパッケージが削除されるかアップグレードされるまでそのパッケージのインストールまたはアップグレードを中止します。
</p>
</sect>
<sect id="virtual"><heading><!-- Virtual packages - <tt>Provides</tt>-->
仮想パッケージ - <tt>Provides</tt>
</heading>
<p> <!--
As well as the names of actual (`concrete') packages, the
package relationship fields <tt>Depends</tt>,
<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
<tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Conflicts</tt>,
<tt>Build-Conflicts</tt> and <tt>Build-Conflicts-Indep</tt> may
mention virtual packages. -->
実際に存在する (具体的な) パッケージと同様、パッケージの関連性を記述するフィールド
<tt>Depends</tt>、<tt>Build-Depends</tt>、
<tt>Build-Depends-Indep</tt>、<tt>Recommends</tt>、
<tt>Suggests</tt>、<tt>Conflicts</tt>、<tt>Build-Conflicts</tt> 及び
<tt>Build-Conflicts-Indep</tt>
には、仮想パッケージ名を記述することができます。
</p>
<p> <!--
A virtual package is one which appears in the
<tt>Provides</tt> control file field of another package.
The effect is as if the package(s) which provide a
particular virtual package name had been listed by name
everywhere the virtual package name appears.-->
この仮想パッケージ名は、あるパッケージのコントロールファイルの、
<tt>Provides</tt> フィールドに書かれるものです。
これによって、そのパッケージが所定の仮想パッケージ名が書かれているところすべてにリストされるという扱いになります。
</p>
<p> <!--
If there are both a real and a virtual package of the same
name then the dependency may be satisfied (or the conflict
caused) by either the real package or any of the virtual
packages which provide it. This is so that, for example,
supposing we have-->
同じ名前の実際のパッケージと仮想パッケージが存在していた場合、依存関係は、そのパッケージによって、満足されたりされなかったりします。例えば、
<example>
Package: vm
Depends: emacs
</example>
<!-- and someone else releases an xemacs package they can say-->
というパッケージがあった場合、他の xemacs のパッケージが、
<example>
Package: xemacs
Provides: emacs
</example> <!-- and all will work in the interim (until a purely
virtual package name is decided on and the <tt>emacs</tt>
and <tt>vm</tt> packages are changed to use it).-->
という宣言をしていた場合、とりあえずすべて正常に動作します
(ただし、純粋な仮想パッケージ名が選ばれて、<tt>emacs</tt> や
<tt>vm</tt> がそれを使うように変更されるまでですが)。
</p>
<p> <!--
If a dependency or a conflict has a version number attached
then only real packages will be considered to see whether
the relationship is satisfied (or the prohibition violated,
for a conflict) - it is assumed that a real package which
provides the virtual package is not of the `right' version.
So, a <tt>Provides</tt> field may not contain version
numbers, and the version number of the concrete package
which provides a particular virtual package will not be
looked at when considering a dependency on or conflict with
the virtual package name.-->
依存や競合関係にバージョン番号が付けられている場合は、
関係が満たされているかどうか (あるいは、競合関係が侵されていないか)
を見るのには、実在のパッケージだけが考慮されます。
仮想パッケージを提供する実在のパッケージは、「正しい」バージョン番号ではないと見なされます。
従って、<tt>Provides</tt> フィールドには、バージョン番号を含んではいけません。
また、仮想パッケージとの競合または依存関係を決定するときには、その仮想パッケージを提供する実際のパッケージのバージョン番号は参照されません。
</p>
<p> <!--
It is likely that the ability will be added in a future
release of <prgn>dpkg</prgn> to specify a version number for
each virtual package it provides. This feature is not yet
present, however, and is expected to be used only
infrequently.-->
将来的には、<prgn>dpkg</prgn> に提供される仮想パッケージのバージョン番号を特定する機能が付加されることになるとは思います。
しかし、この機能は今はまだ実装されていませんし、またそれはめったに使われないことと思います。
</p>
<p> <!--
If you want to specify which of a set of real packages should be the
default to satisfy a particular dependency on a virtual package, you
should list the real package as an alternative before the virtual.-->
ある仮想パッケージに関する依存関係で特定の実際のパッケージの集合を指定しなければならないときには、
仮想パッケージ名の前に、代替パッケージとして使われる実際のパッケージ名をフィールド中に列挙してください。
</p>
</sect>
<sect id="replaces"><heading><!-- <tt>Replaces</tt> - overwriting
files and replacing packages-->
<tt>Replaces</tt> - ファイルの上書きとパッケージの置換
</heading>
<p> <!--
The <tt>Replaces</tt> control file field has two purposes,
which come into play in different situations.-->
コントロールファイルの <tt>Replaces</tt> フィールドは、異なった状況下で作用する二つの目的を持っています。
</p>
<p> <!--
Virtual packages (<ref id="virtual">) are not considered
when looking at a <tt>Replaces</tt> field - the packages
declared as being replaced must be mentioned by their real
names.-->
<tt>Replaces</tt> フィールドでは仮想パッケージ (<ref id="virtual">)
は考慮されません。
このフィールドに置換されるパッケージを宣言するときは、
実際のパッケージ名を使用してください。
</p>
<sect1><heading><!-- Overwriting files in other packages-->
他のパッケージ中の一部のファイルを上書きする
</heading>
<p> <!--
Firstly, as mentioned before, it is usually an error for a
package to contain files which are on the system in
another package, though currently the
<tt>--force-overwrite</tt> flag is enabled by default,
downgrading the error to a warning,-->
まず、以前言及したように、システム中の他のパッケージに含まれているファイルをインストールしようとするパッケージが含んでいるケースは、通常エラーです。
<!-- しかし、現在のところ、dpkg のオプション
<tt>--force-overwrite</tt> がデフォルトでオンになっており、
このエラーは警告に格下げされています。-->
<!-- 訳注：前と不整合。ここは オフになるよう訳者権限で変更 -->
</p>
<p> <!--
If the overwriting package declares that it replaces the
one containing the file being overwritten then
<prgn>dpkg</prgn> will proceed, and replace the file from
the old package with that from the new. The file will no
longer be listed as `owned' by the old package.-->
ここで、インストールパッケージが、システム中のあるファイルを置換すると宣言していた場合、
<prgn>dpkg</prgn> はその処理を実行します。
そして、古いパッケージ中のファイルを新しいファイルと置き換えます。
そのファイルは古いパッケージの所有リストからは削除されます。
</p>
<p> <!--
If a package is completely replaced in this way, so that
<prgn>dpkg</prgn> does not know of any files it still
contains, it is considered to have disappeared. It will
be marked as not wanted on the system (selected for
removal) and not installed. Any conffiles details noted
in the package will be ignored, as they will have been
taken over by the replacing package(s). The package's
<prgn>postrm</prgn> script will be run to allow the
package to do any final cleanup required. See <ref
id="mscriptsinstact">.-->
このようにして、パッケージが完全に置き換えられてしまったときは、
<prgn>dpkg</prgn> はそのパッケージが持っているファイルが無く、
消えてしまったと考えます。この場合、「必要とされていない」
(削除の選択がされた) および「インストールされていない」
とのマークを古いパッケージに付けます。
そのパッケージの設定ファイル関係の詳細は無視されます。
これは、新しいパッケージによって引き継がれているだろうからです。
最終的な大掃除が必要であれば、そのパッケージの <prgn>postrm</prgn>
スクリプトを必要に応じて実行することになるでしょう。
<ref id="mscriptsinstact"> をごらんください。
</p>
<p> <!--
In the future <prgn>dpkg</prgn> will discard files which
would overwrite those from an already installed package
which declares that it replaces the package being
installed. This is so that you can install an older
version of a package without problems.-->
将来の <prgn>dpkg</prgn> では、すでにインストールされているパッケージがこれからインストールしようとするパッケージを置き換える
(Replace) と指定されているときには、
すでにインストールされているパッケージが上書きすると宣言しているファイルは削除されるようになる予定です。
これによって、古いバージョンのパッケージを問題なく上書きインストールできるようになります。
</p>
<p> <!--
This usage of <tt>Replaces</tt> only takes effect when
both packages are at least partially on the system at
once, so that it can only happen if they do not conflict
or if the conflict has been overridden.-->
<tt>Replaces</tt> フィールドがこのように使われるのは、
二つのパッケージが一時的にせよシステム中に同時に存在する場合です。
つまり、これらのパッケージは競合関係にないか、またはその競合関係がすでに上書きされて解消されている場合です。</p>
</sect1>
<sect1><heading><!-- Replacing whole packages, forcing their
removal-->パッケージ全体の削除を伴う置換
</heading>
<p> <!--
Secondly, <tt>Replaces</tt> allows the packaging system to
resolve which package should be removed when there is a
conflict - see <ref id="conflicts">. This usage only
takes effect when the two packages <em>do</em> conflict,
so that the two effects do not interfere with each other.-->
もう一つは、<tt>Replaces</tt> が、競合が起きた際にパッケージ管理システムにどのパッケージを削除するのか指示する場合です。
これについては <ref id="conflicts"> を参照ください。
この使い方が有効なのは、二つのパッケージが <em>実際に競合している</em> 場合です。
従って、前節の場合とこの場合がお互いに干渉することはありません。
</p>
</sect1>
</sect>
<sect><heading><!-- Relationships between source and binary packages -
<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
<tt>Build-Conflicts</tt>, <tt>Build-Conflicts-Indep</tt>-->
ソースパッケージとバイナリパッケージ間の関連 -
<tt>Build-Depends</tt>、<tt>Build-Depends-Indep</tt>、
<tt>Build-Conflicts</tt>、<tt>Build-Conflicts-Indep</tt>
</heading>
<p><!--
A source package may declare a dependency or a conflict on a
binary package. This is done with the control file fields
<tt>Build-Depends</tt>, <tt>Build-Depends-Indep</tt>,
<tt>Build-Conflicts</tt>, and
<tt>Build-Conflicts-Indep</tt>. Their semantics are that
the dependencies and conflicts they define must be satisfied
(as defined earlier for binary packages), when one of the
targets in <tt>debian/rules</tt> that the particular field
applies to is invoked.-->
ソースパッケージはバイナリパッケージに対する依存、あるいは競合関係を宣言することができます。
これはコントロールファイルの <tt>Build-Depends</tt>、
<tt>Build-Depends-Indep</tt>、<tt>Build-Conflicts</tt> 及び
<tt>Build-Conflicts-Indep</tt> を使って指定します。
これらは、<tt>debian/rules</tt> 中のターゲットのうちで、
適用を受ける特定のフィールドが呼び出されたときに、
定義されている依存、あるいは衝突関係による要件が満たされていなければならない
(上でバイナリパッケージに対して定義したのと同じように)
という意味です。
<taglist>
<tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
<item>
<p>
<!-- The <tt>Build-Depends</tt> and
<tt>Build-Conflicts</tt> fields apply to the targets
<tt>build</tt>, <tt>binary</tt>, <tt>binary-arch</tt>
and <tt>binary-indep</tt>.-->
<tt>Build-Depends</tt> と <tt>Build-Conflicts</tt> フィールドは
<tt>build</tt>、<tt>binary</tt>、<tt>binary-arch</tt> と
<tt>binary-indep</tt> ターゲットに適用されます。
</p>
</item>
<tag><tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts-Indep</tt></tag>
<item>
<p><!--
The <tt>Build-Depends-Indep</tt> and
<tt>Build-Conflicts-Indep</tt> fields apply to the
targets <tt>binary</tt> and <tt>binary-indep</tt>.-->
<tt>Build-Depends-Indep</tt> と
<tt>Build-Conflicts-Indep</tt> フィールドは <tt>binary</tt>
と <tt>binary-indep</tt> ターゲットに適用されます。
</p>
</item>
</taglist>
</p>
</sect>
</chapt>
<chapt id="conffiles"><heading><!-- Configuration file handling-->
設定ファイルの取り扱い
</heading>
<p> <!--
<prgn>dpkg</prgn> can do a certain amount of automatic
handling of package configuration files.-->
<prgn>dpkg</prgn>
はパッケージ設定ファイルをある程度自動的に操作できます。
</p>
<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 <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.-->
簡単な方法は、パッケージ中にできうる限り最良のパッケージ設定ファイルを含んだ形でリリースし、以降の更新には
<prgn>dpkg</prgn> の構成ファイルメカニズムを使用するやりかたです。
設定ファイルをユーザが編集することがなさそうでも、仮に編集していた場合にはその編集が失われないようにしたい、
そしてそのパッケージの新しいバージョンはそんなに頻繁にはリリースされない、そんな場合にはこれはよいアプローチです。
</p>
<p> <!--
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.-->
より複雑な方法として、設定ファイルを <prgn>postinst</prgn>
スクリプト中で一から構成し、パッケージの以前のバージョンでの間違いを自動的に修正する責任を持つやり方です。
これは、構成ファイルがそれぞれのシステムによって違う場合には適切な方法です。
</p>
</chapt>
<chapt id="sharedlibs"><heading><!-- Shared libraries-->共有ライブラリ
</heading>
<p> <!--
Packages containing shared libraries must be constructed with
a little care to make sure that the shared library is always
available. This is especially important for packages whose
shared libraries are vitally important, such as the libc.-->
共有ライブラリを含むパッケージの場合、その共有ライブラリがつねに使用可能となるように多少の注意を払って作成しなければなりません。
とりわけ、libc などのシステム運用に関わる重要な共有ライブラリのときは特にこのことは重要です。
</p>
<p> <!--
Firstly, your package should install the shared libraries
under their normal names. For example, the
<prgn>libgdbm1</prgn> package should install
<tt>libgdbm.so.1.7.3</tt> as
<tt>/usr/lib/libgdbm.so.1.7.3</tt>. The files should not be
renamed or re-linked by any prerm or postrm scripts;
<prgn>dpkg</prgn> will take care of renaming things safely
without affecting running programs, and attempts to interfere
with this are likely to lead to problems.-->
初めに、パッケージは、共有ライブラリを普通の名前でインストールするべきです。
例えば、パッケージ <prgn>libgdbm1</prgn> は <tt>libgdbm.so.1.7.3</tt>
を <tt>/usr/lib/libgdbm.so.1.7.3</tt> へインストールすべきです。
このファイルを prerm や postrm スクリプトから名前を変更したり、
再リンクしたりすべきではありません。<prgn>dpkg</prgn>
が実行中のプログラムに影響がないように、注意してファイル名の変更などの作業を実行しますし、これと競合するような処理はおそらく問題を起こすでしょう。
</p>
<p> <!--
Secondly, your package should include the symlink that
<prgn>ldconfig</prgn> would create for the shared libraries.
For example, the <prgn>libgdbm1</prgn> package should include
a symlink from <tt>/usr/lib/libgdbm.so.1</tt> to
<tt>libgdbm.so.1.7.3</tt>. This is needed so that
<prgn>ld.so</prgn> can find the library in between the time
<prgn>dpkg</prgn> installs it and <prgn>ldconfig</prgn> is run
in the <prgn>postinst</prgn> script. Furthermore, older
versions of the package management system required the library
must be placed before the symlink pointing to it in the
<tt>.deb</tt> file. This is so that by the time
<prgn>dpkg</prgn> comes to install the symlink (overwriting
the previous symlink pointing at an older version of the
library) the new shared library is already in place.
Unfortunately, this was not not always possible, since it
highly depends on the behavior of the file system. Some
file systems (such as reiserfs) will reorder the files so it
doesn't matter in what order you create them. Starting with
release <tt>1.7.0</tt> <prgn>dpkg</prgn> will reorder the
files itself when building a package.-->
次に、パッケージは <prgn>ldconfig</prgn>
の作成する共有ライブラリ用のシンボリックリンクを含むべきです。
例えば、<prgn>libgdbm1</prgn> パッケージは、
<tt>/usr/lib/libgdbm.so.1</tt> から <tt>libgdbm.so.1.7.3</tt>
を含むべきです。これが必要なのは、<prgn>dpkg</prgn>
がライブラリをインストールしてから <prgn>postinst</prgn> で
<prgn>ldconfig</prgn> が実行されるまでの間に <prgn>ld.so</prgn>
がそのライブラリを見つけることができるようにするためです。
さらに、古いバージョンのパッケージ管理システムでは、<tt>.deb</tt>
ファイル中のライブラリは、それへのシンボリックリンクが置かれるより先に置かれていることを要求していました。
これは、<prgn>dpkg</prgn> が (古いバージョンのライブラリを指すシンボリックリンクを上書きすることによって)
新しいシンボリックリンクをインストールする時点で、新しい共有ライブラリが既に存在していることを保証するためです。
あいにく、これはいつでも可能なことと言うわけではありませんでした。
なぜなら、それはファイルシステムのふるまいに大きく依存するからです。
ある種の (reiserfs のような)
ファイルシステムはファイルを作る順番が問題にならないように、ファイルを並び換えます。
リリース <tt>1.7.0</tt> から、パッケージ作成時に <prgn>dpkg</prgn>
が自動的にファイルそれ自身を並び換えるようになります。
</p>
<p> <!--
Thirdly, the development package should contain a symlink for
the shared library without a version number. For example, the
<tt>libgdbm1-dev</tt> package should include a symlink from
<tt>/usr/lib/libgdm.so</tt> to <tt>libgdm.so.1.7.3</tt>. This
symlink is needed by <prgn>ld</prgn> when compiling packages
as it will only look for <tt>libgdm.so</tt> and
<tt>libgdm.a</tt> when compiling dynamically or statically,
respectively.-->
三番目に、開発版 (development) パッケージは、バージョン番号なしの共有ライブラリへのシンボリックリンクを含むべきです。
例えば、<tt>libgdbm1-dev</tt> パッケージは、<tt>/usr/lib/libgdm.so</tt>
から <tt>libgdm.so.1.7.3</tt>
へのシンボリックリンクを含むようにすべきです。
このシンボリックリンクが必要となるのは、パッケージをコンパイルするときに
<prgn>ld</prgn> は動的にリンクする際には <tt>libgdm.so</tt> しか、
静的にリンクする際には <tt>libgdm.a</tt> しか探さないからです。
</p>
<p> <!--
Any package installing shared libraries in a directory that's listed
in <tt>/etc/ld.so.conf</tt> or in one of the default library
directories of <prgn>ld.so</prgn> (currently, these are <tt>/usr/lib</tt>
and <tt>/lib</tt>) must call <prgn>ldconfig</prgn> in its <prgn>postinst</prgn>
script if and only if the first argument is `configure'. However, it
is important not to call <prgn>ldconfig</prgn> in the postrm or preinst
scripts in the case where the package is being upgraded (see <ref
id="unpackphase">), as <prgn>ldconfig</prgn> will see the temporary names
that <prgn>dpkg</prgn> uses for the files while it is
installing them and will make the shared library links point
to them, just before <prgn>dpkg</prgn> continues the
installation and removes the links!-->
共有ライブラリを、<tt>/etc/ld.so.conf</tt> に書かれてあるディレクトリか、<prgn>ld.so</prgn> によるデフォルトの検索ディレクトリ
(現在のところ <tt>/usr/lib</tt> と <tt>/lib</tt> です)
のいずれかにインストールするパッケージは、 最初の引数が `configure'
であったとき、かつそのときのみ <prgn>postinst</prgn> スクリプト中で
<prgn>ldconfig</prgn> を呼ばなければなりません。
注意しなければならないのは、パッケージをアップグレードしよう
(<ref id="unpackphase"> 参照) とするときに
postrm や preinst の中から <prgn>ldconfig</prgn>
を呼ばないようにすることです。その場合には <prgn>dpkg</prgn>
がインストールしている間に使う一時的なファイルを
<prgn>ldconfig</prgn> が見てしまい、<prgn>dpkg</prgn>
がインストールを進めてそのリンク先を消してしまう直前に、
<prgn>ldconfig</prgn> は共有ライブラリリンクがその一時的なファイルを指すようにしてしまうからです。
</p>
<sect id="shlibs"><heading><!-- The <tt>shlibs</tt> File Format-->
<tt>shlibs</tt> ファイルの書式
</heading>
<p> <!--
This file is for use by <prgn>dpkg-shlibdeps</prgn> and is
required when your package provides shared libraries.-->
このファイルは、<prgn>dpkg-shlibdeps</prgn> によって使用され、
共有ライブラリを含むパッケージを提供する場合は必須です。
</p>
<p>
<!-- Each line is of the form:-->それぞれの行はつぎのものから構成されます。
<example>
<var>library-name</var> <var>version-or-soname</var> <var>dependencies ...</var>
</example>
</p>
<p> <!--
<var>library-name</var> is the name of the shared library,
for example <tt>libc5</tt>.-->
<var>library-name</var> は、共有ライブラリの名前です。
例えば、<tt>libc5</tt> です。
</p>
<p> <!--
<var>version-or-soname</var> is the soname of the library -
i.e., the thing that must exactly match for the library to be
recognized by <prgn>ld.so</prgn>. Usually this is the major
version number of the library.-->
<var>version-or-soname</var> は、ライブラリの .so ファイル名です。
つまり、<prgn>ld.so</prgn> に認識されるライブラリ名と厳密に一致した名前を与えなければいけません。
これはふつうは、ライブラリのメジャーバージョン番号です。
</p>
<p> <!--
<var>dependencies</var> has the same syntax as a dependency
field in a binary package control file. It should give
details of which package(s) are required to satisfy a binary
built against the version of the library contained in the
package. See <ref id="depsyntax">.-->
<var>dependencies</var> は、バイナリパッケージのコントロールファイル中の
dependency フィールドと同じ書式です。
ここには、そのパッケージに含まれるライブラリでビルドしたバイナリが動作するためにどのパッケージが必要になるかに関する詳細を記述しておくべきです。
<ref id="depsyntax"> を参照ください。
</p>
<p> <!--
For example, if the package <tt>foo</tt> contains
<tt>libfoo.so.1.2.3</tt>, where the soname of the library is
<tt>libfoo.so.1</tt>, and the first version of the package
which contained a minor number of at least <tt>2.3</tt> was
<var>1.2.3-1</var>, then the package's <var>shlibs</var>
could say:-->
例えば、パッケージ <tt>foo</tt> が、<tt>libfoo.so.1.2.3</tt>
を含む場合、ライブラリの .so ファイル名は <tt>libfoo.so.1</tt>
となります。そして、マイナーバージョンが少なくとも <tt>2.3</tt>
であるような最初のパッケージのバージョンは、<var>1.2.3-1</var>
となります。その状況で、パッケージの <var>shlibs</var>
には次のように書きます。
<example>
libfoo 1 foo (>= 1.2.3-1)
</example>
</p>
<p> <!--
The version-specific dependency is to avoid warnings from
<prgn>ld.so</prgn> about using older shared libraries with
newer binaries.-->
特定のバージョン番号への依存関係は、古いバージョンの共有ライブラリで新しいバイナリを実行しようとした際に、
<prgn>ld.so</prgn> が出力する警告を回避するのに役立ちます。
</p>
</sect>
<sect><heading><!-- Further Technical information on
<tt>shlibs</tt>--><tt>shlibs</tt>に関する技術情報の詳細</heading>
<sect1><heading><!-- <em>What</em> are the <tt>shlibs</tt> files?-->
<tt>shlibs</tt> とは <em>何か</em>
</heading>
<p> <!--
The <tt>debian/shlibs</tt> file provides a way of checking
for shared library dependencies on packaged binaries.
They are intended to be used by package maintainers to
make their lives easier.-->
<tt>debian/shlibs</tt> ファイルは、パッケージ化されたバイナリがどの共有ライブラリに依存しているか調べる方法を提供します。
このファイルを使用する目的は、パッケージメンテナが自分の作業を楽にするためです。
</p>
<p> <!--
Other <tt>shlibs</tt> files that exist on a Debian system are-->
Debian システム上にある他の <tt>shlibs</tt> ファイルを次に列挙します。
<list>
<item> <p><tt>/etc/dpkg/shlibs.default</tt></p></item>
<item> <p><tt>/etc/dpkg/shlibs.override</tt></p></item>
<item> <p><tt>/var/lib/dpkg/info/*.shlibs</tt></p></item>
<item> <p><tt>debian/shlibs.local</tt></p></item>
</list>
<!-- These files are used by <prgn>dpkg-shlibdeps</prgn> when
creating a binary package.-->
<prgn>dpkg-shlibdeps</prgn> はバイナリパッケージのビルド時これらのファイルを使います。</p>
</sect1>
<sect1><heading><!-- <em>How</em> does <prgn>dpkg-shlibdeps</prgn>
work?-->
<prgn>dpkg-shlibdeps</prgn> は <em>どのように</em> 動作するのか？
</heading>
<p>
<prgn>dpkg-shlibdeps</prgn>
<!-- determines the shared libraries directly-->
は、コマンドラインから入力されたコンパイル済のバイナリとライブラリが直接使っている共有ライブラリを
<footnote>
<p> <!--
It used to do this by calling <prgn>ldd</prgn>, but it
now calls <prgn>objdump</prgn> to do this. This
requires a couple of changes in the way that packages
are built.-->
以前は <prgn>ldd</prgn> を読んでこの処理を行っていましたが、
現在は <prgn>objdump</prgn> を呼ぶようになっています。
これによってパッケージビルド方法にいくつかの変更が必要になっています。
</p>
<p><!--
A binary <tt>foo</tt> directly uses a library
<tt>libbar</tt> if it is linked with that
library. Other libraries that are needed by
<tt>libbar</tt> are linked indirectly to <tt>foo</tt>,
and the dynamic linker will load them automatically
when it loads <tt>libbar</tt>. Running<prgn>ldd</prgn>
lists all of the libraries used, both directly and
indirectly; but <prgn>objdump</prgn> only lists the
directly linked libraries. A package only needs to
depend on the libraries it is directly linked to,
since the dependencies for those libraries should
automatically pull in the other libraries.-->
バイナリ <tt>foo</tt> がライブラリ <tt>libbar</tt>
にリンクされている場合、このバイナリはこのライブラリを直接使っています。
<tt>libbar</tt> が必要とするその他のライブラリは
<tt>foo</tt> に間接的にリンクされており、ダイナミックリンカは
<tt>libbar</tt> をロードする際に自動的にそれらのライブラリをロードします。
<prgn>ldd</prgn> を使うと、直接使われているライブラリと間接的に使われているライブラリのすべてが列挙されます。
一方、<prgn>objdump</prgn>
は直接使われているライブラリのみを列挙します。
間接的に使われているライブラリは自動的に引いてこられるため、
パッケージが依存関係を指定する必要があるのは直接リンクしているライブラリだけです。
</p>
<p><!--
This change does mean a change in the way packages are
build though: currently <prgn>dpkg-shlibdeps</prgn> is
only run on binaries. But since we will now rely on the
libraries depending on the libraries they themselves
need, the packages containing those libraries will
need to run <prgn>dpkg-shlibdeps</prgn> on the
libraries.-->
この変更は、パッケージのビルド方法に変更があることを意味します。
現在、<prgn>dpkg-shlibdeps</prgn>
はバイナリに対してのみ実行されています。
しかし、この変更によってあるライブラリが他のライブラリを必要とするという依存関係も使うことになるため、
そのような依存関係をもつライブラリを使用する場合には
<prgn>dpkg-shlibdeps</prgn> を実行する必要があります。
<!-- 時制が転んでいる。objdump を使うように変更済みのため、こうしなければならない、であって、今後こうする、ではないはず。-->
</p>
<p><!--
A good example where this would help us is the current
mess with multiple version of the <tt>mesa</tt>
library. With the <prgn>ldd</prgn>-based system, every
package that uses <tt>mesa</tt> needs to add a
dependency on <tt>svgalib|svgalib-dummy</tt> in order
to handle the glide <tt>mesa</tt> variant. With an
<prgn>objdump</prgn>-based system this isn't necessary
anymore and would have saved everyone a lot of work.-->
このことについての理解を助けとなる良い例が、複数のバージョンの
<tt>mesa</tt> ライブラリにたいする現在の混乱です。
<prgn>ldd</prgn> を基本としたシステムでは、<tt>mesa</tt>
を使う全てのパッケージは、glide の <tt>mesa</tt>
派生物を扱うため <tt>svgalib|svgalib-dummy</tt>
への依存関係を加える必要があります。
<prgn>objdump</prgn>
を基本としたシステムでは、このような処置はもはや必要でなく、
全ての人のたくさんの労力を省くことができます。
</p>
<p><!--
Another example: we could update <tt>libimlib</tt>
with a new version that supports a new graphics format
called dgf. If we use the old <prgn>ldd</prgn> method,
every package that uses <tt>libimlib</tt> would need
to be recompiled so it would also depend on
<tt>libdgf</tt> or it wouldn't run due to missing
symbols. However with the new system, packages using
<tt>libimlib</tt> can rely on <tt>libimlib</tt> itself
having the dependency on <tt>libdgf</tt> and wouldn't
need to be updated.-->
例をもうひとつ挙げます。<tt>libimlib</tt> を dgf
という新しいグラフィックフォーマットに対応した、新しいバージョンに更新する場合を考えます。
もし、古い <prgn>ldd</prgn> による方法を用いるとすれば、
<tt>libimlib</tt> を使うパッケージは全て <tt>libdgf</tt>
にも依存するようにコンパイルしなおさなければなりません。
そうしなければ missing symbols となって実行できません。
しかし、新しいシステムでは、<tt>libimlib</tt> 自身に
<tt>libdgf</tt> への依存関係を持たせられるので、
<tt>libimlib</tt> を使っているパッケージは <tt>libimlib</tt>
への依存関係を指定しておけば更新する必要がありません。
</p>
</footnote>
調べます。
<!-- used by the compiled binaries and libraries passed through
on its command line.-->
</p>
<p>
<!-- For each shared library linked to,
<prgn>dpkg-shlibdeps</prgn> needs to know-->
各共有ライブラリに対して、<prgn>dpkg-shlibdeps</prgn>
は次の情報を把握する必要があり、
<list compact="compact">
<item><p>the package containing the library, and</p></item>
<item><p>the library version number,</p></item>
</list>
<!-- and it scans the following files in this order:-->
そのために次のファイルをここに書かれている順に走査します。
<enumlist compact="compact">
<item><p><tt>debian/shlibs.local</tt></p></item>
<item><p><tt>/etc/dpkg/shlibs.override</tt></p></item>
<item><p><tt>/var/lib/dpkg/info/*.shlibs</tt></p></item>
<item><p><tt>/etc/dpkg/shlibs.default</tt></p></item>
</enumlist></p>
</sect1>
<sect1><heading><!-- <em>Who</em> maintains the various
<tt>shlibs</tt> files-->
様々な <tt>shlibs</tt> ファイルを <em>誰が</em> 管理しているのか？
</heading>
<p>
<list compact="compact">
<item>
<p><!-- <tt>/etc/dpkg/shlibs.default</tt> - the maintainer
of dpkg-->
<tt>/etc/dpkg/shlibs.default</tt> - dpkg のメンテナ </p>
</item>
<item>
<p>
<tt>/var/lib/dpkg/info/<var>package</var>.shlibs</tt>
<!-- - the maintainer of each package-->
- それぞれのパッケージのメンテナ</p>
</item>
<item>
<p>
<!-- <tt>/etc/dpkg/shlibs.override</tt> - the local
system administrator-->
<tt>/etc/dpkg/shlibs.override</tt> - ローカルのシステム管理者
</p>
</item>
<item>
<p><!-- <tt>debian/shlibs.local</tt> - the maintainer of
the package-->
<tt>debian/shlibs.local</tt> - そのパッケージのメンテナ
</p>
</item>
</list>
<!-- The <tt>shlibs.default</tt> file is managed by
<prgn>dpkg</prgn>. The entries in <tt>shlibs.default</tt>
that are provided by <prgn>dpkg</prgn> are just there to
fix things until the shared library packages all have
<tt>shlibs</tt> files.-->
<tt>shlibs.default</tt> ファイルは、<prgn>dpkg</prgn>
が管理しています。<prgn>dpkg</prgn> によって提供される
<tt>shlibs.default</tt> の各エントリは、共有ライブラリパッケージすべてが、それぞれの
<tt>shlibs</tt> ファイルを持つようになるまで、既定値を決めるために置かれています。
</p>
</sect1>
<sect1><heading><!--<em>How</em> to use <prgn>dpkg-shlibdeps</prgn> and
the <tt>shlibs</tt> files?-->
<prgn>dpkg-shlibdeps</prgn> と <tt>shlibs</tt> ファイルを <em>どのようにして</em> 使うか ?
</heading>
<sect2><heading><!-- If your package doesn't provide a shared
library-->
あなたのパッケージが共有ライブラリを含んでいないとき
</heading>
<p> <!--
Put a call to <prgn>dpkg-shlibdeps</prgn> into your
<tt>debian/rules</tt> file. If your package contains
only binaries (e.g. no scripts) use:-->
<tt>debian/rules</tt> ファイル中に <prgn>dpkg-shlibdeps</prgn>
への呼出しルーチンを置いてください。バイナリだけを含んだパッケージ
(つまり、スクリプトを含まない) の場合、次を使用してください。
<example>
dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/*
</example>
<!-- If <prgn>dpkg-shlibdeps</prgn> doesn't complain, you're
done. If it does complain you might need to create your
own <tt>debian/shlibs.local</tt> file.-->
<prgn>dpkg-shlibdeps</prgn>
が何も文句を言ってこなかったなら、うまくいっています。
もし、エラーや警告などが出力されたのであれば、たぶん、自前の
<tt>debian/shlibs.local</tt> を作成する必要があるでしょう。</p>
</sect2>
<sect2><heading><!--If your package provides a shared library-->
あなたのパッケージが共有ライブラリを含んでいるとき
</heading>
<p> <!--
Create a <tt>debian/shlibs</tt> file and let
<tt>debian/rules</tt> install it in the control area:-->
<tt>debian/shlibs</tt> ファイルを作成して、<tt>debian/rules</tt>
でそれを制御領域にインストールしてください。
<example>
install -m644 debian/shlibs debian/tmp/DEBIAN
</example>
<!-- If your package contains additional binaries see above.-->
もし、あなたのパッケージが他のバイナリを含んでいるのであれば、
前項の記述を参照してください。
</p>
</sect2>
</sect1>
<sect1><heading><!-- <em>How</em> to write-->
<tt>debian/shlibs.local</tt> を <em>どのように</em> 書くのか
</heading>
<p> <!--
This file is intended only as a <em>temporary</em> fix if
your binaries depend on a library which doesn't provide
its own <tt>/var/lib/dpkg/info/*.shlibs</tt> file yet.-->
このファイルは、あなたの作ったパッケージが、そのパッケージ用の
<tt>/var/lib/dpkg/info/*.shlibs</tt>
をまだ提供していないライブラリに依存しているときの
<em>一時的</em> 解決のためのものです。
</p>
<p> <!--
Let's assume you are packaging a binary <tt>foo</tt>. Your
output in building the package might look like this.-->
バイナリ <tt>foo</tt> をパッケージ作成中だとします。
ビルドの際のメッセージが、例えば次のようになっていて、
<example>
$ ldd foo
libbar.so.1 => /usr/X11R6/lib/libbar.so.1.0 (0x4001e000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4002c000)
libc.so.6 => /lib/libc.so.6 (0x40114000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
</example>
<!-- And when you ran <prgn>dpkg-shlibdeps</prgn>-->
<prgn>dpkg-shlibdeps</prgn> を実行すると、次のようになっている場合
<example>
$ dpkg-shlibdeps -O foo
dpkg-shlibdeps: warning: unable to find dependency information for shared library libbar (soname 1, path /usr/X11R6/lib/libbar.so.1.0, dependency field Depends)
shlibs:Depends=libc6 (>= 2.2.1), xlibs (>= 4.0.1-11)
</example>
<!-- The <prgn>foo</prgn> binary depends on the
<prgn>libbar</prgn> shared library, but no package seems
to provide a <tt>*.shlibs</tt> file in
<tt>/var/lib/dpkg/info/</tt>. Let's determine the package
responsible:-->
<prgn>foo</prgn> バイナリは、
<prgn>libbar</prgn> 共有ライブラリに依存していますが、
<tt>/var/lib/dpkg/info/</tt> に <tt>*.shlibs</tt>
ファイルを提供しているパッケージはないようです。
というわけで、責任をとるパッケージを決定しましょう。
</p>
<p>
<example>
$ dpkg -S /usr/X11R6/lib/libbar.so.1.0
bar1: /usr/X11R6/lib/libbar.so.1.0
$ dpkg -s bar1 | grep Version
Version: 1.0-1
</example><!--
This tells us that the <prgn>bar1</prgn> package, version
1.0-1 is the one we are using. Now we can create our own
<tt>debian/shlibs.local</tt> to temporarily fix the above
problem. Include the following line into your
<tt>debian/shlibs.local</tt> file.-->
どうやら、<prgn>bar1</prgn> パッケージのバージョン 1.0-1
が現在我々の使用しているものということのようです。
ここで、この問題を一時的に解決するために、自分専用の
<tt>debian/shlibs.local</tt> を作ります。次の行を、
<tt>debian/shlibs.local</tt> 中に含めてください。
<example>
libbar 1 bar1 (>= 1.0-1)
</example>
<!-- Now your package build should work. As soon as the
maintainer of <prgn>libbar1</prgn> provides a
<tt>shlibs</tt> file, you can remove your
<tt>debian/shlibs.local</tt> file.-->
さあ、これであなたのパッケージビルド作業はうまくいくはずです。
<prgn>libbar1</prgn> のパッケージメンテナにより、そのパッケージ用の
<tt>shlibs</tt> ファイルが提供されしだい、あなたの
<tt>debian/shlibs.local</tt> ファイルを削除することができます。
</p>
</sect1>
</sect>
</chapt>
<chapt>
<!-- <heading>The Operating System</heading> -->
<heading>オペレーティングシステム</heading>
<sect>
<!-- <heading>File system hierarchy</heading> -->
<heading>ファイルシステムの階層構造</heading>
<sect1>
<!-- <heading>Linux File system Structure</heading> -->
<heading>Linux ファイルシステム構造</heading>
<p>
<!--
The location of all installed files and directories must
comply with the Linux File system Hierarchy Standard
(FHS). The latest version of this document can be found
alongside this manual or on
<url id="http://www.pathname.com/fhs/";>.
Specific questions about following the standard may be
asked on <prgn>debian-devel</prgn>, or referred to Daniel
Quinlan, the FHS coordinator, at
<email>quinlan@xxxxxxxxxxxx</email>.
-->
インストールされるファイルやディレクトリの配置はすべて Linux
File system Hierarchy Standard (FHS) に従わなければなりません。
この文書の最新版は本マニュアルと一緒に配布されていますし、
<url id="http://www.pathname.com/fhs/";> にもあります。
下記の標準に対する質問は <prgn>debian-devel</prgn> に送るか、
もしくは FHS の責任者である Daniel Quinlan
<email>quinlan@xxxxxxxxxxxx</email> に問い合わせて下さい。
</p></sect1>
<sect1>
<!-- <heading>Site-specific programs</heading> -->
<heading>サイト毎のプログラム</heading>
<p>
<!--
As mandated by the FHS, package must not place any
files in <tt>/usr/local</tt>, either by putting them in
the file system archive to be unpacked by
<prgn>dpkg</prgn> or by manipulating them in their
maintainer scripts.
-->
FHS に従うため、パッケージは <tt>/usr/local/</tt>
以下にファイルをおいてはいけません。それが
<prgn>dpkg</prgn>
によって展開されるアーカイブファイルの中身であっても、メンテナスクリプトによって作成されるようなファイルであっても置いてはいけません。
</p>
<p>
<!-- However, the package may create empty directories
below <tt>/usr/local</tt> so that the system administrator
knows where to place site-specific files. These
directories should be removed on package removal if they
are empty. -->
しかし、サイト特有のファイルを置く場所がシステム管理者にわかるように、空のディレクトリを
<tt>/usr/local</tt> 以下のディレクトリ中に作ることはかまいません。
これらのディレクトリは、パッケージの削除の際に
(それが空であれば) 同時に削除される様になっていなければいけません。
</p>
<p>
<!-- Note, that this applies only to directories
<em>below</em> <tt>/usr/local</tt>, not <em>in</em>
<tt>/usr/local</tt>. Packages must not create sub-directories
in the directory <tt>/usr/local</tt> itself, except those
listed in FHS, section 4.5. However, you may create directories
below them as you wish. You must not remove any of the directories
listed in 4.5, even if you created them.
-->
このようなパッケージ固有のディレクトリを作成していいのは
<tt>/usr/local</tt> <em>より一段以上深い</em>
ディレクトリだけで、<tt>/usr/local</tt>
直下に作成してはいけないことに注意して下さい。パッケージから
<tt>/usr/local</tt> ディレクトリ直下には FHS のセクション 4.5
に列挙されているサブディレクトリ以外のものを作成してはいけません。
しかし、それら列挙されたディレクトリの下には自由にサブディレクトリを作ってもかまいません。
もし自分で作ったディレクトリであったとしても、セクション
4.5 に列挙されているディレクトリは消してはいけません。
</p>
<p>
<!-- Since <tt>/usr/local</tt> can be mounted read-only
from a remote server, these directories must be created
and removed by the <tt>postinst</tt> and <tt>prerm</tt>
maintainer scripts. These scripts must not fail if either
of these operations fail. (In the future, it will be
possible to tell <prgn>dpkg</prgn> not to unpack files
matching certain patterns, so that the directories can be
included in the <tt>.deb</tt> packages and system
administrators who do not wish these directories in
/usr/local do not need to have them.)-->
<tt>/usr/local</tt> がリモートのサーバからリードオンリーでマウントされていている場合に対処するため、
それらのディレクトリはメンテナスクリプトである
<tt>postinst</tt> や <tt>prerm</tt> から作成や削除を行わなければいけません。
これらのスクリプトはそういった作業に失敗しても、それ自身が落ちるようなことがあってはいけません。
(将来的には、特定のパターンに該当するファイルを
<prgn>dpkg</prgn> が展開しないよう指示を出せるようになるでしょう。
これにより、<tt>.deb</tt> パッケージに
<tt>/usr/local</tt> 配下のディレクトリが含められていても、
システム管理者が不用と思えばインストールされることはなくなります。)
</p>
<p>
<!--
For example, the <prgn>emacs</prgn> package will contain
<example>
mkdir -p /usr/local/lib/emacs/site-lisp || true
</example>
in the <tt>postinst</tt> script, and
<example>
rmdir /usr/local/lib/emacs/site-lisp || true
rmdir /usr/local/lib/emacs || true
</example>
in the <tt>prerm</tt> script.
-->
例えば、<prgn>emacs</prgn>パッケージは、<tt>postinst</tt>に
<example>
mkdir -p /usr/local/lib/emacs/site-lisp || true
</example>
を含め、<tt>prerm</tt>に
<example>
rmdir /usr/local/lib/emacs/site-lisp && \
rmdir /usr/local/lib/emacs || \
true
</example>
を入れることになるでしょう。
</p>
<p>
<!-- If you do create a directory in <tt>/usr/local</tt>
for local additions to a package, you should ensure that
settings in <tt>/usr/local</tt> take precedence over the
equivalents in <tt>/usr</tt>. -->
あるパッケージ用にローカルな追加をするために
<tt>/usr/local</tt> 配下にディレクトリを作成した場合、
<tt>/usr/local</tt> 配下の設定が <tt>/usr</tt>
配下のものより優先されるよう保証しておくべきです。
</p>
<p>
<!-- However, because '/usr/local' and its contents are
for exclusive use of the local administrator, a package
must not rely on the presence or absence of files or
directories in '/usr/local' for normal operation. -->
しかし '/usr/local'
と、その中身は、ローカルの管理者が占有して利用する為にあるのであって、通常の利用においてパッケージがそれらファイルやディレクトリの有無に依存することがあってはなりません。
</p>
<p>
<!-- The <tt>/usr/local</tt> directory itself and all the
subdirectories created by the package should (by default) have
permissions 2775 (group-writable and set-group-id) and be
owned by <tt>root.staff</tt>. -->
<tt>/usr/loca/</tt>ディレクトリ自身と、パッケージによって作成されたそのサブディレクトリは、既定のパーミッションとして
2775 (group 書き込み許可、group id セット) を、そしてオーナーとしては <tt>root.staff</tt> を設定しておくべきです。
</p>
</sect1>
<sect1>
<!--<heading>The system-wide mail directory</heading>-->
<heading>システムで使うメールディレクトリ</heading>
<p><!--
The system-wide mail directory is <tt>/var/mail</tt>. This
directory is part of the base system and should not owned
by any particular mail agents. The use of the old
location <tt>/var/spool/mail</tt> is deprecated, even
though the spool may still be physically located there.
To maintain partial upgrade compatibility for systems
which have <tt>/var/spool/mail</tt> as their physical mail
spool, packages using <tt>/var/mail</tt> must depend on
either <package>libc6</package> (>= 2.1.3-13), or on
<package>base-files</package> (>= 2.2.0), or on later
versions of either one of these packages. -->
システムで使うメールディレクトリは <tt>/var/mail</tt> です。
このディレクトリは基本システムの一部で、特定のメールエージェントに属しているべきではありません。
以前の場所の <tt>/var/spool/mail</tt> は、スプールの実体が依然として物理的にその場所に置かれている場合に於いても、使うべきではありません。
物理メールスプールが <tt>/var/spool/mail</tt>
であるようなシステムからの部分アップグレード時の互換性を維持するため、<tt>/var/mail</tt>
を用いるパッケージは <package>libc6</package> (>= 2.1.3-13)
か <package>base-files</package> (>= 2.2.0)
への、またはこのどちらかのパッケージのこれ以降のバージョンへの依存関係を宣言しなければいけません。
</p>
</sect1>
</sect>
<sect id="users_and_groups">
<!-- <heading>Users and groups</heading> -->
<heading>ユーザとグループ</heading>
<p>
<!-- The Debian system can be configured to use either plain or
shadow passwords.-->
Debian システムは平文パスワードとシャドウパスワードのいずれの設定とすることも可能です。
</p>
<p>
<!-- Some user ids (UIDs) and group ids (GIDs) are reserved
globally for use by certain packages. Because some packages
need to include files which are owned by these users or
groups, or need the ids compiled into binaries, these ids
must be used on any Debian system only for the purpose for
which they are allocated. This is a serious restriction, and
we should avoid getting in the way of local administration
policies. In particular, many sites allocate users and/or
local system groups starting at 100.-->
一部のユーザ ID(UID) とグループ ID(GID)
は特定のパッケージで使用するため、ディストリビューションとして予約されています。
いくつかのパッケージではこれらのユーザやグループに所有されたファイルを同梱することが必要だったり、プログラムにこれらの
ID をコンパイル時に組み込んだりする必要があるため、Debian
システムではこれらの ID
は割り当てられた目的のためだけに使用が許されています。
これは重大な制限で、個々のサイトローカルな管理方針を取り入れてはいけません。
特に多くのサイトではローカルなユーザやシステムグループの ID を 100
から順に割り振っていますので、この制約に注意してください。
</p>
<p>
<!-- Apart from this we should have dynamically allocated ids,
which should by default be arranged in some sensible
order -- but the behavior should be configurable.-->
これとは別に動的に割り当てられる ID があります。このような ID
は所定の妥当な順で配置されていくようになっていますが、この配置の挙動は設定可能です。</p>
<p>
<!-- Packages other than `base-passwd' must not modify
<tt>/etc/passwd</tt>, <tt>/etc/shadow</tt>, <tt>/etc/group</tt>
or <tt>/etc/gshadow</tt>.-->
<tt>base-passwd</tt> 以外のパッケージは <tt>/etc/passwd</tt>、
<tt>/etc/shadow</tt>、<tt>/etc/group</tt> および
<tt>/etc/gshadow</tt> を変更してはいけません。</p>
<p>
<!-- The UID and GID ranges are as follows: -->
UID と GID の割り当てを下記に示します。
<taglist>
<tag>0-99:</tag>
<item>
<p>
<!-- Globally allocated by the Debian project, the
same on every Debian system. These ids will appear in
the <tt>passwd</tt> and <tt>group</tt> files of all
Debian systems, new ids in this range being added
automatically as the <tt>base-passwd</tt> package is
updated.-->
Debian プロジェクトで共通に割り当てられ、すべての Debian
システムで同じ目的のために使われるものです。これらの ID
はすべての Debian システムの <tt>passwd</tt> と
<tt>group</tt> に現れ、<tt>base-passwd</tt>
更新の際にこの範囲にある ID は自動的に追加されます。</p>
<p>
<!-- Packages which need a single statically allocated uid
or gid should use one of these; their maintainers
should ask the <tt>base-passwd</tt> maintainer for
ids.-->
静的に割り当てられた uid や gid が必要なパッケージはこの範囲の
ID を使わなければなりません。当該パッケージのメンテナは
ID を <tt>base-passwd</tt> のメンテナに割り当ててもらう必要があります。
</p>
</item>
<tag>100-999:</tag>
<item>
<p>
<!-- Dynamically allocated system users and groups.
Packages which need a user or group, but can have this
user or group allocated dynamically and differently on
each system, should use `<tt>adduser --system</tt>' to
create the group and/or user. <prgn>adduser</prgn>
will check for the existence of the user or group, and
if necessary choose an unused id based on the ranges
specified in <tt>adduser.conf</tt>.-->
動的に割り当てられるシステム用のユーザアカウントです。
パッケージでユーザやグループの割り当てが必要ではあるけれども、それらが
動的に割り当てられた、システム毎に異なるものでも構わない場合には、
<tt>adduser --system</tt> を使ってこの範囲のユーザやグループを作成してください。
<prgn>adduser</prgn>
は個々のユーザやグループの有無をチェックします。また必要なら
<tt>adduser.conf</tt> の範囲指定で使わない ID を選択してください。
</p></item>
<tag>1000-29999:</tag>
<item>
<p>
<!-- Dynamically allocated user accounts. By default
<prgn>adduser</prgn> will choose UIDs and GIDs for
user accounts in this range, though
<tt>adduser.conf</tt> may be used to modify this
behavior.-->
動的に割り当てられるユーザアカウントです。標準設定の
<prgn>adduser</prgn> はこの範囲の UID と GID
を割り当てますが、この動作は <tt>adduser.conf</tt>
で変更することができます。
</p>
</item>
<tag>30000-59999:</tag>
<item>
<!-- <p>Reserved.</p></item> -->
<p>予約されています。</p></item>
<tag>60000-64999:</tag>
<item>
<p>
<!-- Globally allocated by the Debian project, but only
created on demand. The ids are allocated centrally and
statically, but the actual accounts are only created
on users' systems on demand.-->
Debian プロジェクトとして共通に割り当てているものですが、
要求に応じて作成されます。ID
自体は集中管理で、静的に割り当てられているものですが、実際のアカウント作成は必要になった時点で行われます。
</p>
<p>
<!-- These ids are for packages which are obscure or which
require many statically-allocated ids. These packages
should check for and create the accounts in
<tt>/etc/passwd</tt> or <tt>/etc/group</tt> (using
<prgn>adduser</prgn> if it has this facility) if
necessary. Packages which are likely to require
further allocations should have a `hole' left after
them in the allocation, to give them room to
grow.-->
これらの ID はあまり使われないパッケージや、多くの静的に割り当てられた
ID を必要とするパッケージのためのものです。
このようなパッケージでは <tt>/etc/passwd</tt> や
<tt>/etc/group</tt> を調べて、(<prgn>adduser</prgn>
があるなら使って)
必要に応じてアカウントを作成しなければいけません。
引き続いて ID を要求していく可能性のあるようなパッケージでは、割り当てた
ID の後に将来の追加のために保留部を残しておかなければいけません。
</p></item>
<tag>65000-65533:</tag>
<item>
<!-- <p>Reserved.</p></item> -->
<p>予約されています。</p></item>
<tag>65534:</tag>
<item>
<!-- <p>User `<tt>nobody</tt>.'</p></item> -->
<p>ユーザ `<tt>nobody</tt>' に割り当てられています。このユーザ
id はグループ `<tt>nogroup</tt>' に割り当ててください。</p></item>
<tag>65535:</tag>
<item>
<p>
<!-- <tt>(uid_t)(-1) == (gid_t)(-1)</tt>. NOT TO BE USED,
because it is the error return sentinel value.</p> -->
<tt>(uid_t)(-1) == (gid_t)(-1)</tt>. この値はエラー検出判定に用いるため、使わないでください。
</p>
</item>
</taglist>
</p>
</sect>
<sect id="sysvinit">
<!-- <heading>System run levels</heading> -->
<heading>システムランレベル</heading>
<sect1 id="/etc/init.d">
<!-- <heading>Introduction</heading> -->
<heading>はじめに</heading>
<p>
<!-- The <tt>/etc/init.d</tt> directory contains the scripts
executed by <prgn>init</prgn> at boot time and when init
state (or `runlevel') is changed (see <manref name="init"
section="8">).-->
<tt>/etc/init.d</tt> ディレクトリにはブート時と init の状態
(ランレベル) が変わったときに (<manref name="init" section="8">
参照)、<prgn>init</prgn> に実行されるスクリプトが納められてい
ます。</p>
<p>
<!-- There are at least two different, yet functionally
equivalent, ways of handling these scripts. For the sake
of simplicity, this document describes only the symbolic
link method. However, it must not be assumed by maintainer
scripts that this method is being used, and any automated
manipulation of the various runlevel behaviours by
maintainer scripts must be performed using `update-rc.d'
as described below and not by manually installing or
removing symlinks. For information on the
implementation details of the other method, implemented in
the <tt>file-rc</tt> package, please refer to the
documentation of that package. -->
これらのスクリプトを用いるにあたり、少なくとも二つ
(機能上は等しいものですが) の方法があります。簡単のため、
このドキュメントではシンボリックリンクによる方法のみを記します。
しかし、メンテナスクリプト中でこの方法だけが用いられていると思い込んではなりません。
また、それぞれのランレベルの挙動に対する操作は、
手でシンボリックリンクを作成することで実行せず、後述するように
<prgn>update-rc.d</prgn> によって行われなくてはなりません。
<tt>file-rc</tt> パッケージで実装されている、もう一つの方法による実装の詳細については、当該パッケージのドキュメントを参照して下さい。
</p>
<p>
<!-- These scripts are referenced by symbolic links in
the <tt>/etc/rc<var>n</var>.d</tt> directories. When
changing runlevels, <prgn>init</prgn> looks in the
directory <tt>/etc/rc<var>n</var>.d</tt> for the scripts
it should execute, where <var>n</var> is the runlevel that
is being changed to, or `S' for the boot-up scripts. -->
これらのスクリプトは <tt>/etc/rc<var>n</var>.d</tt>
ディレクトリの中からシンボリックリンクが張られています。
ランレベルを変更すると、<prgn>init</prgn>は
<tt>/etc/rc<var>n</var>.d</tt> ディレクトリ内を見て、
実行すべきスクリプトを探します。ここで <var>n</var>
は、これから変更されるランレベルを示します。
また `S' はブート時のスクリプトを指します。
</p>
<p>
<!-- The names of the links all have the form
<tt>S<var>mm</var><var>script</var></tt> or
<tt>K<var>mm</var><var>script</var></tt> where
<var>mm</var> is a two-digit number and <var>script</var>
is the name of the script (this should be the same as the
name of the actual script in <tt>/etc/init.d</tt>. -->
リンクの名前は全て
<tt>S<var>mm</var><var>script</var></tt> か
<tt>K<var>mm</var><var>script</var></tt> の形をとっています。
ここで <var>mm</var> は二桁の数字で、<var>script</var>
はスクリプトの名前を示しています (この名前は
<tt>/etc/init.d</tt>
内の実際のスクリプトと同一の名前にしておくべきです)。
</p>
<p>
<!-- When <prgn>init</prgn> changes runlevel first the
targets of the links whose names starting with a
<tt>K</tt> are executed, each with the single argument
<tt>stop</tt>, followed by the scripts prefixed with an
<tt>S</tt>, each with the single argument <tt>start</tt>.
The <tt>K</tt> links are responsible for killing services
and the <tt>S</tt> link for starting services upon
entering the runlevel. -->
<prgn>init</prgn> がランレベルを変更したとき、まず名前が <tt>K</tt>
で始まるシンボリックリンクの先のスクリプトが、それぞれ
<tt>stop</tt> オプション付きで実行されます。次に
<tt>S</tt> で始まるスクリプトが <tt>start</tt>
オプション付きで起動されていきます。<tt>K</tt>
で始まる名前でリンクを張られたものは、サービスを停止することに対応し、<tt>S</tt>
の方は、そのランレベルになる時にサービスを開始することを示します。
</p>
<p>
<!-- For example, if we are changing from runlevel 2 to
runlevel 3, init will first execute all of the <tt>K</tt>
prefixed scripts it finds in <tt>/etc/rc3.d</tt>, and then
all of the <tt>S</tt> prefixed scripts. The links
starting with <tt>K</tt> will cause the referred-to file
to be executed with an argument of <tt>stop</tt>, and the
<tt>S</tt> links with an argument of <tt>start</tt>. -->
例えば、ランレベル 2 から 3 へと移行したとします。
<prgn>init</prgn> は、まず <tt>/etc/rc3.d/</tt> にある全ての
<tt>K</tt> で始まるスクリプトを、その後 <tt>S</tt>
で始まるスクリプトを実行していきます。<tt>K</tt>
で始まるものはそれぞれに対応したファイルを <tt>stop</tt>
オプション付きで、そして
<tt>S</tt> で始まるリンク先を <tt>start</tt> オプション付きで実行します。
</p>
<p>
<!-- The two-digit number <var>mm</var> is used to decide
which order to start and stop things in-low-numbered links
have their scripts run first. For example, the
<tt>K20</tt> scripts will be executed before the
<tt>K30</tt> scripts. This is used when a certain service
must be started before another. For example, the name
server <prgn>bind</prgn> might need to be started before
the news server <prgn>inn</prgn> so that <prgn>inn</prgn>
can set up its access lists. In this case, the script
that starts <prgn>bind</prgn> would have a lower number
than the script that starts <prgn>inn</prgn> so that it
runs first: -->
<var>mm</var> で示した二桁の数字は、どういう順序で開始及び停止を行うかを決定するのに用いられます。
小さい数字から順番に実行されます。
例えば <tt>K20</tt> というふうに始まるスクリプトは
<tt>K30</tt> で始まるものよりも先に実行されます。
あるサービスが他のサービスよりも先に開始していなければならないときに使うわけです。
例えば、ネームサーバ <prgn>bind</prgn>
はニュースサーバ <prgn>inn</prgn> がアクセスリストをセットアップできるよう、先に起動しておく必要があるでしょう。
このケースでは <prgn>bind</prgn> を起動するスクリプトは
<prgn>inn</prgn> を起動するものよりも小さい番号にします。
<example>
/etc/rc2.d/S17bind
/etc/rc2.d/S70inn
</example>
</p>
</sect1>
<sect1>
<!-- <heading>Writing the scripts</heading> -->
<heading>スクリプトの書き方</heading>
<p>
<!-- Packages that include daemons for system services should
place scripts in <tt>/etc/init.d</tt> to start or stop services
at boot time or during a change of runlevel. These scripts
should be named <tt>/etc/init.d/<var>package</var></tt>,
and they should accept one argument, saying what to do: -->
システムサービスを行うデーモンを含むパッケージはブート時やランレベル変更時にサービスを開始及び停止させるため、
<tt>/etc/init.d</tt> にスクリプトを置くべきです。
このスクリプトは、<tt>/etc/init.d/<var>package</var></tt>
という名前にすべきで、何を行うかを指定する一つの引数を取るようにすべきです。
<taglist>
<tag><tt>start</tt></tag>
<item>
<p>
<!-- start the service, -->
サービスを開始します。
</p></item>
<tag><tt>stop</tt></tag>
<item>
<p>
<!-- stop the service, -->
サービスを停止します。
</p></item>
<tag><tt>restart</tt></tag>
<item>
<p>
<!-- stop and restart the service,-->
サービスを停止し、再起動します。
</p></item>
<tag><tt>reload</tt></tag>
<item>
<p>
<!-- cause the configuration of the service to be
reloaded without actually stopping and restarting
the service, -->
サービスを停止したり再起動することなく、サービスの設定を再読み込みします。
</p></item>
<tag><tt>force-reload</tt></tag>
<item>
<p>
<!-- cause the configuration to be reloaded if the
service supports this, otherwise restart the
service. -->
サービスが設定の再読み込みに対応しているならば再読み込みを行います。
対応していないなら再起動します。
</p></item>
</taglist>
<!-- The <tt>start</tt>, <tt>stop</tt>, <tt>restart</tt>,
and <tt>force-reload</tt> options must be supported by all
scripts in <tt>/etc/init.d</tt>, the <tt>reload</tt>
option is optional. -->
<tt>start</tt>、<tt>stop</tt>、<tt>restart</tt>、
<tt>force-reload</tt> の各オプションは
<tt>/etc/init.d</tt> 内の全てのスクリプトがサポートしていなければなりませんが、
<tt>reload</tt> オプションのサポートは任意です。
</p>
<p>
<!-- The <tt>init.d</tt> scripts should ensure that they
will behave sensibly if invoked with <tt>start</tt> when
the service is already running, or with <tt>stop</tt> when
it isn't, and that they don't kill unfortunately-named
user processes. The best way to achieve this is usually
to use <prgn>start-stop-daemon</prgn>. -->
<tt>init.d</tt> スクリプトは、該当するサービスが既に起動しているのに
<tt>start</tt> オプション付きで実行された場合の動作に慎重さが要求されます。
逆に起動していないのに
<tt>stop</tt> オプション付きで実行された際には、他のユーザープロセスを落さないようにしなくてはなりません。
ベストの方法は常に、
<prgn>start-stop-daemon</prgn> を用いるようにすることです。
</p>
<p>
<!-- If a service reloads its configuration automatically
(as in the case of <prgn>cron</prgn>, for example), the
<tt>reload</tt> option of the <tt>init.d</tt> script
should behave as if the configuration has been reloaded
successfully. -->
もしサービスが設定を自動的に再読み込みするような場合 (例えば
<prgn>cron</prgn> などで)、<tt>init.d</tt> スクリプトに付けられた
<tt>reload</tt> オプションは、
再読み込みに成功したかのように振舞う必要があります。
</p>
<p>
<!-- These scripts should not fail obscurely when the
configuration files remain but the package has been
removed, as configuration files remain on the system after
the package has been removed. Only when <prgn>dpkg</prgn>
is executed with the <tt>-purge</tt> option will
configuration files be removed. In particular, the init
script itself is usually a configuration file (see <ref
id="init.d notes">), and will remain on the system if the
package is removed but not purged. Therefore, you should
include a <tt>test</tt> statement at the top of the
script, like this: -->
パッケージ自体が削除されていても設定ファイルはシステムに残っているため、
その状態でこれらのスクリプトは不可解な落ち方をしないようにすべきです。
<prgn>dpkg</prgn> は
<tt>--purge</tt> オプション付きで実行されて初めて設定ファイルを削除します。
特に init スクリプト自体も通常設定ファイル
(<ref id="init.d notes">参照) ですので、
パッケージが削除されても上記オプションが指定されていない場合ではスクリプトはシステムに残ったままになっています。
このため、次のように <tt>test</tt> 文をスクリプトの先頭におくべきです。
<example>
test -f <var>program-executed-later-in-script</var> || exit 0
</example></p>
<p><!--
Often there are some values in the `<tt>init.d</tt>'
scripts that a system administrator will frequently want
to change. While the scripts are frequently conffiles,
modifying them requires that the administrator merge in
their changes each time the package is upgraded and the
conffile changes. To ease the burden on the system
administrator, such configurable values should not be
placed directly in the script. Instead, they should be
placed in a file in `<tt>/etc/default</tt>', which
typically will have the same base name as the
`<tt>init.d</tt>' script. This extra file can be sourced
by the script when the script runs. It must contain only
variable settings and comments.-->
`<tt>init.d</tt>' スクリプト中には管理者がしばしば変更したいような
値をいくつか含む場合が良くあります。
スクリプトは多くの場合 conffile ですので、スクリプトを変更した場合管理者がパッケージアップグレードの際に変更された
conffile に対して変更をマージする必要があります。
このシステム管理者の負担を軽減するため、そのような設定可能な値はスクリプト中に直接書かないようにしてください。
その代わりに、そのような値は `<tt>/etc/default</tt>' 中のファイルによって与えます。
このファイルは通常 `<tt>init.d</tt>' スクリプトと同じ名前にしてください。
この追加ファイルは `<tt>init.d</tt>' スクリプトを実行する際に参照されます。
このファイルには変数設定と、コメント以外を書かないでください。
</p>
<p><!--
To ensure that vital configurable values are always
available, the `<tt>init.d</tt>' script should set default
values for each of the shell variables it uses before
sourcing the <tt>/etc/default/</tt> file. Also, since the
`<tt>/etc/default/</tt>' file is often a conffile, the
`<tt>init.d</tt>' script must behave sensibly without
failing if it is deleted.-->
必要な設定値がいつも存在していることを保証するため、
`<tt>init.d</tt>' スクリプト中で <tt>/etc/default/</tt>
ファイルを取り込む前に各シェル変数に既定の値を設定して置いてください。
また、`<tt>/etc/default/</tt>' もしばしば conffile ですので、
`<tt>init.d</tt>' スクリプトはそれが消されていた場合にも失敗することなく妥当に振る舞わなければいけません。
</p>
</sect1>
<sect1>
<!-- <heading>Managing the links</heading> -->
<heading>リンクの取り扱い</heading>
<p>
<!-- A program <prgn>update-rc.d</prgn> is provided to
make it easier for package maintainers to arrange for the
proper creation and removal of
<tt>/etc/rc<var>n</var>.d</tt> symbolic links, or their
functional equivalent if another method is being used.
This may be used by maintainers in their packages'
<tt>postinst</tt> and <tt>postrm</tt> scripts. -->
<tt>/etc/rc<var>n</var>.d</tt> のシンボリックリンクの作成と削除
(前に触れたもう一つの方法を用いている場合には機能的に等価な処理になります)
の作業をパッケージメンテナが簡単にできるようにするため、
<prgn>update-rc.d</prgn> というプログラムが配布されています。
このプログラムは、メンテナがパッケージ内の
<tt>postinst</tt> や <tt>postrm</tt> スクリプトの中で使います。
</p>
<p>
<!-- You must use this script to make changes to
<tt>/etc/rc<var>n</var>.d</tt> and <em>never</em> either
include any <tt>/etc/rc<var>n</var>.d</tt> symbolic links
in the actual archive or manually create or remove the
symbolic links in maintainer scripts. (The latter will
fail if an alternative method of maintaining runlevel
information is being used.) -->
<tt>/etc/rc<var>n</var>.d</tt> に変更を加えるときには必ず
このスクリプトを用い、<em>絶対に</em>
<tt>/etc/rc<var>n</var>.d</tt>
内のシンボリックリンクを直接アーカイブに含めたり、メンテナスクリプトによってシンボリックリンクの作成及び削除を行ってはなりません
(後者の方法は、ランレベル情報の取り扱いをもう一つの方法で行っている場合には正しく動作しません)。
</p>
<p>
<!-- By default <prgn>update-rc.d</prgn> will start
services in each of the multi-user state runlevels (2, 3,
4, and 5) and stop them in the halt runlevel (0), the
single-user runlevel (1) and the reboot runlevel (6). The
system administrator will have the opportunity to
customize runlevels by either running
<prgn>update-rc.d</prgn>, by simply adding, moving, or
removing the symbolic links in
<tt>/etc/rc<var>n</var>.d</tt> if symbolic links are being
used, or by modifying <tt>/etc/runlevel.conf</tt> if the
<tt>file-rc</tt> method is being used. -->
デフォルトでは、<prgn>update-rc.d</prgn> はマルチユーザー状態の各ランレベル
(2,3,4,5) にて、各種サービスを開始させ、
halt(0)、シングルユーザー(1)、リブート(6)
の各ランレベルでは停止するようにします。
システムの管理者は <prgn>update-rc.d </prgn> を実行して、
シンボリックリンクによる管理がなされている場合には <tt>/etc/rc<var>n</var>.d</tt>
のシンボリックリンクを追加、移動、削除することによって、また、<tt>file-rc</tt>
による方法で管理されていれば
<tt>/etc/runlevel.conf</tt> を変更することによって、ランレベルをカスタマイズすることができます。
</p>
<p>
<!-- To get the default behavior for your package, put in
your <tt>postinst</tt> script -->
自分のパッケージをデフォルトの挙動を持つものとして設定するには、
<tt>postinst</tt> スクリプトに次のように書きます。
<example>
update-rc.d <var>package</var> defaults >/dev/null
</example>
<!-- and in your <tt>postrm</tt> -->
<tt>postrm</tt> では次のようになります。
<example>
if [ purge = "$1" ]; then
update-rc.d <var>package</var> remove >/dev/null
fi
</example>
</p>
<p>
<!-- This will use a default sequence number of 20. If it
does not matter when or in which order the script is run,
use this default. If it does, then you should talk to the
maintainer of the <prgn>sysvinit</prgn> package or post to
<tt>debian-devel</tt>, and they will help you choose a
number. -->
この方法ではデフォルトのシーケンス番号として 20 が使われます。
スクリプトを動かす際、その順序で問題なければ、
このデフォルトを使うようにして下さい。そうでなければ
<prgn>sysvinit</prgn> パッケージのメンテナと連絡をとるか、
<tt>debian-devel</tt> にポストしましょう。
番号の選択について手助けしてもらえるはずです。
</p>
<p>
<!-- For more information about using
<tt>update-rc.d</tt>, please consult its manpage <manref
name="update-rc.d" section="8">. -->
<tt>update-rc.d</tt>の使い方に関する情報は、man <manref
name="update-rc.d" section="8"> を見て下さい。
</p>
</sect1>
<sect1>
<!-- <heading>Boot-time initialization</heading> -->
<heading> ブート時における初期化 </heading>
<p>
<!-- There used to be another directory,
<tt>/etc/rc.boot</tt>, which contained scripts which were
run once per machine boot. This has been deprecated in
favour of links from <tt>/etc/rcS.d</tt> to files in
<tt>/etc/init.d</tt> as described in <ref
id="/etc/init.d">. No packages may place files in
<tt>/etc/rc.boot</tt>. -->
ホストをブートした時に一度だけ実行されるスクリプトをまとめた
<tt>/etc/rc.boot</tt> なるディレクトリが昔は存在しましたが、
<ref id="/etc/init.d"> でも記載した通り、<tt>/etc/rcS.d</tt> から
<tt>/etc/init.d</tt> 内のファイルへのリンクに置き換えることが強く推奨されています。
パッケージが <tt>/etc/rc.boot</tt> にファイルを置くことは許されていません。
</p><!-- file-rc 採用時のやり方と記載が矛盾するが、不問 -->
<sect1 id="init.d notes">
<!-- <heading>Notes</heading> -->
<heading>付記</heading>
<p>
<!-- <em>Do not</em> include the
<tt>/etc/rc<var>n</var>.d/*</tt> symbolic links in the
<tt>.deb</tt> file system archive! <em>This will cause
problems!</em> You must create them with
<prgn>update-rc.d</prgn>, as above. -->
<tt>/etc/rc<var>n</var>.d</tt> 内のシンボリックリンクを
<tt>.deb</tt> アーカイブに含めることは<em>問題を生ずるため、してはなりません</em>。
上記にあるように、その場合には
<prgn>update-rc.d</prgn> を使わなければいけません。
</p>
<p>
<!-- <em>Do not</em> include the
<tt>/etc/rc<var>n</var>.d/*</tt> symbolic links in
<prgn>dpkg</prgn>'s conffiles list! <em>This will cause
problems!</em> You should, however, treat the
<tt>/etc/init.d</tt> scripts as configuration files,
either by marking them as conffiles or managing them
correctly in the maintainer scripts (see <ref id="config
files">). (This is important since we want to give the
local system administrator the chance to adapt the scripts
to the local system-e.g., to disable a service without
de-installing the package, or to specify some special
command line options when starting a service-while making
sure her changes aren't lost during the next package
upgrade.) -->
<tt>/etc/rc<var>n</var>.d</tt> 内のシンボリックリンクを
<prgn>dpkg</prgn>の conffiles リストに含めることは
<em>問題を引き起こすため、行ってはいけません</em>。
一方、<tt>/etc/init.d</tt>
スクリプトは設定ファイルとして扱うべきです。そのためには
conffile としてマークするか、メンテナスクリプト (<ref id=
"config files">参照) の中で適切に扱うようにしてください
(このことは、ローカルシステムの管理者が、自分達のシステムにあわせたスクリプトの変更ができるようにしておくために重要なことです。
例えば、ローカルシステムの管理者がパッケージを削除すること無くサービスを停止したり、
サービス開始時に特殊なコマンドラインオプションを指定したりする場合、その変更がパッケージのアップグレードの際に失われないようにしなければいけません)。
</p>
</sect1>
<sect1>
<!-- <heading>Example</heading> -->
<heading>実例</heading>
<p>
<!-- The <prgn>bind</prgn> DNS (nameserver) package wants
to make sure that the nameserver is running in multiuser
runlevels, and is properly shut down with the system. It
puts a script in <tt>/etc/init.d</tt>, naming the script
appropriately <tt>bind</tt>. As you can see, the script
interprets the argument <tt>reload</tt> to send the
nameserver a <tt>HUP</tt> signal (causing it to reload its
configuration); this way the user can say
<tt>/etc/init.d/bind reload</tt> to reload the name
server. The script has one configurable value, which can
be used to pass parameters to the named program at
startup.-->
<prgn>bind</prgn> という DNS (ネームサーバ)
パッケージはマルチユーザーのランレベルで稼働されていることが保証されていること、さらにシステムと共にきちんとシャットダウンすることも要求します。
そのためにパッケージは <tt>bind</tt> というスクリプトを
<tt>/etc/init.d</tt> に置きます。
下記スクリプトを見ていただければ分かると思いますが、
このスクリプトは <tt>reload</tt> オプションを、ネームサーバに
<tt>HUP</tt> シグナルを送る (これで設定を再読み込みさせられます)
ことと解釈します。このようにしてユーザーは
<tt>/etc/init.d/bind reload</tt> とすればネームサーバの設定の再読み込みを行うことができます。
このスクリプトは立ち上げ時に named プログラムへパラメータを渡すために使うことができる設定可能な値を含むファイルを一つ持っています。
</p>
<p>
<example>
#!/bin/sh
#
# Original version by Robert Leslie
# <rob@xxxxxxxx>, edited by iwj and cs
test -x /usr/sbin/named || exit 0
# Source defaults file.
PARAMS=''
if [ -f /etc/default/bind ]; then
. /etc/default/bind
fi
case "$1" in
start)
echo -n "Starting domain name service: named"
start-stop-daemon --start --quiet --exec /usr/sbin/named \
-- $PARAMS
echo "."
;;
stop)
echo -n "Stopping domain name service: named"
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
echo "."
;;
restart)
echo -n "Restarting domain name service: named"
start-stop-daemon --stop --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
start-stop-daemon --start --verbose --exec /usr/sbin/named \
-- $PARAMS
echo "."
;;
force-reload|reload)
echo -n "Reloading configuration of domain name service: named"
start-stop-daemon --stop --signal 1 --quiet \
--pidfile /var/run/named.pid --exec /usr/sbin/named
echo "."
;;
*)
echo "Usage: /etc/init.d/bind {start|stop|restart|reload|force-reload}" >&2
exit 1
;;
esac
exit 0
</example>
</p>
<p><!--
Complementing the above init script is a file
'<tt>/etc/default/bind</tt>', which contains configurable
parameters used by the script.-->
上記の init スクリプトを補うファイルが '<tt>/etc/default/bind</tt>'
で、これはこのスクリプト中で使う設定可能なパラメータの値を含んでいます。
</p>
<p>
<example>
# Specified parameters to pass to named. See named(8).
# You may uncomment the following line, and edit to taste.
#PARAMS="-u nobody"
</example>
</p>
<p>
<!-- Another example on which to base your
<tt>/etc/init.d</tt> scripts is in
<tt>/etc/init.d/skeleton</tt>. -->
あなたの<tt>/etc/init.d</tt>スクリプトのベースとなる、別の
サンプルは<tt>/etc/init.d/skeleton</tt>にもあります。
</p>
<p>
<!-- If this package is happy with the default setup from
<prgn>update-rc.d</prgn>, namely an ordering number of 20
and having named running in all runlevels, it can say in
its <tt>postinst</tt>: -->
もしこのパッケージが <prgn>update-rc.d</prgn> のデフォルト設定のまま、
特に起動順序番号が 20 で、かつ named を全てのランレベルで走らせる、
という設定で満足するなら、<tt>postinst</tt> には次のように書けば良いことになります。
<example>
update-rc.d bind defaults >/dev/null
</example>
<!-- And in its <tt>postrm</tt>, to remove the links when
the package is purged: -->
そして<tt>postrm</tt>には、パージの際にそのリンクを削除するために次のように書きます。
<example>
if [ purge = "$1" ]; then
update-rc.d bind remove >/dev/null
fi
</example>
</p>
</sect1>
</sect>
<sect>
<!--<heading>Cron jobs</heading>-->
<heading>Cron ジョブ</heading>
<p><!--
Packages must not modify the configuration file
<tt>/etc/crontab</tt>, and they must not modify the files in
<tt>/var/spool/cron/crontabs</tt>.-->
パッケージは <tt>/etc/crontab</tt> 設定ファイルを変更してはいけません。
また、<tt>/var/spool/cron/crontabs</tt> 内のファイルを変更してもいけません。
</p>
<p><!--
If a package wants to install a job that has to be executed
via cron, it should place a file with the name of the
package in one of the following directories:-->
パッケージが cron で実行されるようなジョブをインストールしたいときは、
下記のディレクトリの一つにパッケージの名前を持つファイルを置いてください。
<!-- if/of -->
<example>
/etc/cron.daily
/etc/cron.weekly
/etc/cron.monthly
</example><!--
As these directory names imply, the files within them are
executed on a daily, weekly, or monthly basis,
respectively. The exact times are listed in
<tt>/etc/crontab</tt>.-->
これらのディレクトリの名前が示す通り、これらの中のファイルはそれぞれ、
毎日(daily)、毎週(weekly)、毎月(monthly) 実行されます。
正確な時刻は <tt>/etc/crontab</tt> に記載されています。</p>
<p><!--
All files installed in any of these directories must be
scripts (shell scripts, Perl scripts, etc.) so that they can
easily be modified by the local system administrator. In
addition, they should be treated as configuration files.-->
これらのディレクトリにインストールされた全てのファイルは、
ローカルシステムの管理者が簡単に変更できるようにスクリプト
(シェルスクリプト、perl スクリプトなど) でなければいけません。また、
設定ファイル (<ref id="config files">参照)
として扱われるようにすべきです。
</p>
<p><!--
If a certain job has to be executed more frequently than
daily, the package should install a file
<tt>/etc/cron.d/<var>package-name</var></tt>. This file uses
the same syntax as <tt>/etc/crontab</tt> and is processed by
<prgn>cron</prgn> automatically. The file must also be
treated as a configuration file. (Note, that entries in the
<tt>/etc/cron.d</tt> directory are not handled by
<prgn>anacron</prgn>. Thus, you should only use this
directory for jobs which may be skipped if the system is not
running.)-->
一日一回より高い頻度で実行する必要のあるジョブがある場合には、
パッケージは <tt>/etc/cron.d/<var>package-name</var></tt>
ファイルをインストールするようにしてください。このファイルは
<tt>/etc/crontab</tt> と同じ書式で、<prgn>cron</prgn>
により自動的に実行されます。
このファイルも設定ファイルとして扱わなければいけません
(注記：この <tt>/etc/cron.d</tt> の中のエントリは
<prgn>anacron</prgn> では処理されないので、ここにおくジョブはシステムが停止しているときには行う必要がないものに限られます。)
</p>
<p><!--
The scripts or crontab entries in these directories should
check if all necessary programs are installed before they
try to execute them. Otherwise, problems will arise when a
package was removed but not purged since configuration files
are kept on the system in this situation.-->
これらのディレクトリにあるスクリプトは、実行する前に必要なプログラムがインストールされているかをチェックするようになっていなければいけません。
そうしないと、パッケージをパージ (完全削除) ではなく単に削除したときには設定ファイルがシステムに残ったままになっているので、問題が起きてしまいます。
</p>
</sect>
<sect>
<!-- <heading>Console messages</heading>-->
<heading>コンソールメッセージ</heading>
<p><!--
This section describes different formats for messages
written to standard output by the <tt>/etc/init.d</tt>
scripts. The intent is to improve the consistency of
Debian's startup and shutdown look and feel.-->
この章では <tt>/etc/init.d</tt> 内のスクリプトが標準出力に書き出す各種のメッセージの書式について述べます。
この規定の狙いは
Debian の起動とシャットダウン時の見栄えをより一貫したものとすることです。
</p>
<p><!--
Please look very careful at the details. We want to get the
messages to look exactly the same way concerning spaces,
punctuation, and case of letters.-->
詳細にわたって、注意深く読んでください。空白や句読点、大文字小文字の使い分けなどが厳密に同じに見えるようにしようと考えています。
</p>
<p><!--
Here is a list of overall rules that you should use when you
create output messages. They can be useful if you have a
non-standard message that isn't covered in the sections
below.-->
まず、出力メッセージを作成する際に使うべき基本的なルールを示します。
この章の以降で扱われていない、標準的ではないメッセージを出力させたいときには参考にしてください。
</p>
<p>
<list>
<item>
<p>
<!--Every message should cover one line, start with a
capital letter and end with a period `.'.-->
全てのメッセージは一行に書かれ、大文字で始まり、ピリオド
`.' で終わらなければなりません</p></item>
<item>
<p><!--
If you want to express that the computer is working on
something (performing a specific task, not starting or
stopping a program), we use an ``ellipsis'', namely
three dots `...'. Note that we don't insert spaces in
front of or behind the dots. If the task has been
completed we write `done.' and a line feed.-->
コンピュータが何かを実行していることを表現したい場合
(プログラムの開始や終了ではなく、特定の作業が進行中である場合などです)
``省略符号(ellipsis)''、すなわち三つのドット
`...' を使います。
ドットの前後にスペースを入れないことに注意してください。
作業が終了したら `done' と表示して改行してください。
</p></item>
<item>
<p><!--
Design your messages as if the computer is telling you
what he is doing (let him be polite :-) but don't
mention ``him'' directly. For example, if you think
of saying-->
コンピュータが何をしているのか教えようとするかのように
メッセージを作成してください。礼儀正しく :-)
但し、コンピュータ自体を主語としては使わないでください。
例えば、
<example>
I'm starting network daemons: nfsd mountd.
</example>
<!-- just say --> と表現したいならば、単に次のようにしてください。
<example>
Starting network daemons: nfsd mountd.
</example></p></item>
</list></p>
<p>
<!-- The following formats should be used</p> -->
下記の場合は、記載の書式を使うようにすべきです。</p>
<p>
<list>
<item>
<p><!-- when daemons get started.-->デーモンを開始するとき</p>
<p><!--
Use this format if your script starts one or more
daemons. The output should look like this (a single
line, no leading spaces):-->
スクリプトが一つ以上のデーモンを起動するときには、次の書式を使います。
出力は次のようにしてください (1行にし、
最初に空白は入れません)。
<example>
Starting <description>: <daemon-1><daemon-2> <...> <daemon-n>.
</example>
<!-- The <description> should describe the subsystem
the daemon or set of daemons are part of, while
<daemon-1> up to <daemon-n> denote each
daemon's name (typically the file name of the
program).-->
<description> は対象となる一つまたは複数のデーモンの属するサブシステムについて記述してください。
<daemon-1>
から始まって <daemon-n> までは各デーモンの名前 (通常はそのプログラムのファイル名) を記載してください。
</p>
<p><!--
For example, the output of /etc/init.d/lpd would look like:-->
例えば <tt>/etc/init.d/lpd</tt> の出力は次のようになります:
<example>
Starting printer spooler: lpd.
</example></p>
<p>
<!-- This can be achieved by saying -->
このように出力するためにスクリプト中では次のようにしています。
<example>
echo -n "Starting printer spooler: lpd"
start-stop-daemon --start --quiet lpd
echo "."
</example>
<!-- in the script. If you have more than one daemon to
start, you should do the following:-->
一つ以上のデーモンを起動するときは次のようにします:
<example>
echo -n "Starting remote file system services:"
echo -n " nfsd"; start-stop-daemon --start --quiet nfsd
echo -n " mountd"; start-stop-daemon --start --quiet mountd
echo -n " ugidd"; start-stop-daemon --start --quiet ugidd
echo "."
</example>
<!--This makes it possible for the user to see what takes
so long and when the final daemon has been
started. You should be careful where to put spaces: In the
example above the system administrator can easily
comment out a line if he don't wants to start a
specific daemon, while the displayed message still
looks good.-->
これによりユーザは何に時間がかかっているのか、またいつ最後のデーモンが起動したのかを知ることができます。
スペースをどこに置くかに気をつけるべきです。
上記の例では、既に述べたように、システム管理者が特定のデーモンを起動したくないときには簡単にコメントアウトできますし、その場合でもメッセージはきちんと表示されます。
</p></item>
<item>
<!-- <p>when something needs to be configured.</p>-->
<p>何か設定する必要があるとき</p>
<p><!--
If you have to set up different parameters of the
system upon boot up, you should use this format:-->
起動時にシステムの設定を変更するときには、次のような書式を使うべきです。
<example>
Setting <parameter> to `<value>'.
</example></p>
<p><!--
You can use the following echo statement to get the
quotes right: -->
引用符が正しくなるようにするには、次の echo 文を使ってください:
<example>
echo "Setting DNS domainname to \`"value"'."
</example></p>
<p><!--
Note that the left quotation mark (`) is different
from the right (').-->
左引用符 (`) と右引用符 (') が違うことに気を付けてください。
</p></item>
<item>
<!-- <p>when a daemon is stopped.</p>-->
<p>デーモンを停止するとき</p>
<p><!--
When you stop a daemon you should issue a message
similar to the startup message, except that `Starting'
is replaced with `Stopping'.-->
デーモンを止めるときのメッセージの書式は起動時のメッセージに準じ、
`Starting' を `Stopping' に変えたものです。</p>
<p>
<!-- So stopping the printer daemon will like like this:-->
従って、プリンタデーモンを止める時の出力は次のようになります:
<example>
Stopping printer spooler: lpd.
</example></p></item>
<item>
<!-- <p>when something is executed.</p>-->
<p>何かを実行しているとき</p>
<p><!--
There are several examples where you have to run a
program at system startup or shutdown to perform a
specific task. For example, setting the system's clock
via `netdate' or killing all processes when the system
comes down. Your message should like this:-->
システムの開始時やシャットダウン時に特定の処理を行うために
プログラムを実行しなければならないようなことはよくあります。
例えば `netdate' でシステムの時計を合わせたり、
システム終了時に全てのプロセスを止めたりなどです。
このような場合のコンソールメッセージは次のようになります。
<example>
Doing something very useful...done.
</example>
<!-- You should print the `done.' right after the job has
been completed,
so that the user gets informed why he has to wait. You
can get this
behavior by saying-->
作業が終了した後は `done.' を表示し、ユーザに何故待たされていたのかを知らせなければいけません。
これは次のようにスクリプトに書きます。
<example>
echo -n "Doing something very useful..."
do_something
echo "done."
</example>
<!-- in your script.--></p></item>
<item>
<!-- <p>when the configuration is reloaded.</p>-->
<p>設定を再読み込みするとき</p>
<p><!--
When a daemon is forced to reload its configuration
files you should use the following format:-->
デーモンが設定ファイルを再読み込みするときは、次の書式を使ってください。
<example>
Reloading <daemon's-name> configuration...done.
</example></p></item>
<item>
<!-- <p>when none of the above rules apply.</p>-->
<p>これまでの規則が当てはまらないとき</p>
<p>
<!-- If you have to print a message that doesn't fit into
the styles described above, you can use something
appropriate, but please have a look at the overall
rules listed above.-->
これまで述べてきた場合に当てはまらないメッセージを表示しなければならない場合、
自分で適切なメッセージを作成して使うことができますが、
最初の項の一般的なルールを良く読んでおいてください。
</p></item>
</list></p></sect>
<sect>
<heading><!-- Menus-->メニュー</heading>
<p><!--
Menu entries should follow the current menu policy as
defined in the file <ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/menu-policy.txt.gz</ftppath>
or your local mirror. In addition, it is included in the
<tt>debian-policy</tt> package.-->
Menu エントリは現在の Menu ポリシーに従う必要があります。この
Menu ポリシーは <ftpsite>ftp.debian.org</ftpsite> の
<ftppath>/debian/doc/package-developer/menu-policy.txt.gz</ftppath>
または手近のミラーサイトに置かれています。また、この Menu ポリシーは
<tt>debian-policy</tt> にも収録されています。
</p>
<p><!--
The Debian <tt>menu</tt> packages provides a unique
interface between packages providing applications and
documents, and <em>menu programs</em> (either X window
managers or text-based menu programs as
<prgn>pdmenu</prgn>).-->
Debian の <tt>menu</tt> パッケージはアプリケーションや文書を提供するパッケージと
<em>メニュープログラム</em> (X window マネージャや
<prgn>pdmenu</prgn> のようなテキストベースのメニュープログラム)
の間の独自のインターフェースを提供します。</p>
<p><!--
All packages that provide applications that need not be
passed any special command line arguments for normal
operation should register a menu entry for those
applications, so that users of the <tt>menu</tt> package
will automatically get menu entries in their window
managers, as well in shells like <tt>pdmenu</tt>.-->
通常の操作において特別な引数を必要としないアプリケーションを提供する全てのパッケージは、
そのアプリケーションに対してメニューエントリ
(menu entry) を登録します。こうすれば <tt>menu</tt>
パッケージを使うユーザはウィンドウマネージャ内や、<tt>pdmenu</tt>
のようなシェルからメニューを自動的に取得できます。</p>
<p><!--
Please refer to the <em>Debian Menu System</em> document
that comes with the <tt>menu</tt> package for information
about how to register your applications and web
documents.-->
アプリケーションや web 文書を登録する方法の詳細については、
<tt>menu</tt> パッケージに付属する <em>Debian メニューシステム
</em> ドキュメントを参照してください。
</p>
</sect>
<sect>
<!-- <heading>Multimedia handlers</heading>-->
<heading>マルチメディアハンドラ</heading>
<p><!--
Packages which provide the ability to view/show/play,
compose, edit or print MIME types should register themselves
as such following the current MIME support policy as defined
in the file found on <ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/mime_policy.txt.gz</ftppath>
or your local mirror. In addition, it is included in the
<tt>debian-policy</tt> package. -->
ある種の MIME タイプを表示/閲覧/再生/合成/編集や印刷する機能を
もつプログラムは <ftpsite>ftp.debian.org</ftpsite> の
<ftppath>/debian/doc/package-developer/mime_policy.txt.gz</ftppath>
または手近のミラーサイトの、現在の MIME サポートポリシーに従って登録を行う必要があります。
この MIME サポートポリシーは
<tt>debian-policy</tt> にも収録されています。
</p>
<p><!--
MIME (Multipurpose Internet Mail Extensions, RFC 1521) is a
mechanism for encoding files and data streams and providing
meta-information about them, in particular their type (e.g.
audio or video) and format (e.g. PNG, HTML, MP3).-->
MIME (Multipurpose Internet Mail Extensions, RFC 1521)
とはファイルやデータストリームを符号化し、それに関するメタ情報、
特に種別 (音声や画像) とフォーマット (PNG、HTML、MP3 など)
などの付随情報を付加するための機構です。
</p>
<p><!--
Registration of MIME type handlers allows programs like mail
user agents and web browsers to to invoke these handlers to
view, edit or display MIME types they don't support
directly.-->
MIME タイプを登録することで、メール受信ユーザプログラムやウェブブラウザがそれ自身で直接扱えない
MIME タイプの表示や編集などをハンドラを呼び出すことで行うことができるようになります。
<!-- view と display は違いが分からないのでカット -->
</p>
</sect>
<sect>
<!-- <heading>Keyboard configuration</heading> -->
<heading>キーボード設定</heading>
<p><!--
To achieve a consistent keyboard configuration (i.e., all
applications interpret a keyboard event the same way) all
programs in the Debian distribution must be configured to
comply with the following guidelines.-->
システムで一貫したキーボードの設定
(すべてのアプリケーションがキーボード打鍵イベントを同じように解釈する)
を実現するために
Debian ディストリビューションのプログラムは下記のガイドラインに従わなければなりません。
</p>
<p><!--
Here is a list that contains certain keys and their interpretation:
-->
以降は特定のキーとその解釈の組です。
<taglist>
<tag><tt><--</tt></tag>
<!-- <item><p>delete the character to the left of the
cursor</p></item>-->
<item><p>カーソルの左の文字を削除する</p></item>
<tag><tt>Delete</tt></tag>
<!-- <item><p>delete the character to the right of the
cursor</p></item>-->
<item><p>カーソルの右の文字を削除する</p></item>
<tag><tt>Control+H</tt></tag>
<!-- <item><p>emacs: the help prefix</p></item>-->
<item><p>emacs では一連のヘルプを呼び出す</p></item>
</taglist>
<!-- The interpretation of any keyboard events should be independent
of the terminal that's used, be it a virtual console, an X
terminal emulator, an rlogin/telnet session, etc.-->
キーボード打鍵イベントの解釈はそのとき使っている端末
(仮想コンソールや X 端末エミュレータ、rlogin/telnet セッションなど)
に依存しないものでなければいけません。</p>
<p>
<!-- The following list explains how the different programs
should be set up to achieve this:-->
下記のリストは異なったプログラムでこれを実現するための説明です。</p>
<p>
<list compact="compact">
<item><p>`<tt><--</tt>'
<!-- generates KB_Backspace in X.-->
X 環境ではバックスペースキーイベントを起こします</p></item>
<item><p>`<tt>Delete</tt>' <!-- generates KB_Delete in X.-->
X 環境では Delete キーイベントを起こします</p></item>
<item>
<p><!--
X translations are set up to make KB_Backspace
generate ASCII DEL, and to make KB_Delete generate
<tt>ESC [ 3 ~</tt> (this is the vt220 escape code for
the `delete character' key). This must be done by
loading the resources using xrdb on all local X
displays, not using the application defaults, so that
the translation resources used correspond to the
xmodmap settings.-->
X 環境ではバックスペースキーイベントは ASCII の DEL を生成し、
Delete キーイベントでは <tt>ESC [ 3 ~</tt>
(これは vt220 のデリートキーのエスケープシーケンスです)
を生成するように設定します。これは全 X 表示画面に対して xrdb
でリソースをロードすることで設定します。アプリケーションの既定設定を変更はしません。
これは xmodmap 設定とここでの解釈のリソースを一致させるためです。
</p></item>
<item>
<p><!--
The Linux console is configured to make
`<tt><--</tt>' generate DEL, and `Delete' generate
<tt>ESC [ 3 ~</tt> (this is the case at the
moment).-->
Linux コンソールは `<tt><--</tt>' は DEL を、
Delete キーは <tt>ESC [ 3 ~</tt> を生成するように設定されています
(現状そうなっています)。</item>
<item><p><!--
X applications are configured so that Backspace
deletes left, and Delete deletes right. Motif
applications already work like this.-->
X アプリケーションはバックスペースキーはカーソルの左を、
Delete キーは右を消すように設定します。Motif アプリケーションは既にこうなっています。
</p></item>
<item><p><!-- stty erase <tt>^?</tt> .-->
stty erase は <tt>^?</tt> と設定します</p></item>
<item><p><!--
The `xterm' terminfo entry should have <tt>ESC [ 3
~</tt> for kdch1, just like TERM=linux and
TERM=vt220.-->
`xterm' の terminfo エントリは kdch1 に
<tt>ESC [ 3 ~</tt> を設定します。TERM=linux と TERM=vt220
も同様です。</p></item>
<item><p><!--
Emacs is programmed to map KB_Backspace or the `stty
erase' character to delete-backward-char, and
KB_Delete or kdch1 to delete-forward-char, and
<tt>^H</tt> to help as always.-->
Emacs は バックスペースキーイベントと、`stty erase'
で設定されたキーイベントは delete-backward-char にマップされ、
Delete キーイベントは delete-forward-char にマップされます。
また、<tt>^H</tt> は常にヘルプの呼び出しです。</p></item>
<item><p><!--
Other applications use the `stty erase' character and
kdch1 for the two delete keys, with ASCII DEL being
`delete previous character' and kdch1 being `delete
character under cursor'.-->
他のアプリケーションでは `stty erase' と kdch1 は二つの
delete キーとして、ASCII DEL 文字は前の文字を消すように、
kdch1 はカーソルの下の文字を消すようにします。</p></item>
</list></p>
<p>
<!--This will solve the problem except for:-->
これで大部分の問題は解決しますが、以降に例外に属する処理について記しておきます。
</p>
<p>
<list compact="compact">
<item><p><!--
Some terminals have a <tt><--</tt> key that cannot
be made to produce anything except <tt>^H</tt>. On
these terminals Emacs help will be unavailable on
<tt>^H</tt> (assuming that the `stty erase' character
takes precedence in Emacs, and has been set
correctly). M-x help or F1 (if available) can be used
instead.-->
一部のターミナルでは <tt><--</tt> キーで <tt>^H</tt>
以外のコードを生成することができません。このようなターミナルでは、
Emacs のヘルプを <tt>^H</tt> で呼ぶことができません
(Emacs では `stty erase' の設定の方が優先され、かつ正しく設定されているという仮定の下です)。
M-x help または F1 (あれば) を代わりに使うことができます。
</p></item>
<item><p><!--
Some operating systems use <tt>^H</tt> for stty erase.
However, modern telnet versions and all rlogin
versions propagate stty settings, and almost all UNIX
versions honour stty erase. Where the stty settings
are not propagated correctly things can be made to
work by using stty manually.-->
一部の OS は <tt>^H</tt> を stty erase の文字に使います。
ただ、最近の telnet やすべての rlogin プログラムは stty
設定を引き継ぎますし、ほとんどすべての UNIX 類は stty
erase の設定を尊重します。stty 設定が正しく引き継がれない場合には、
stty を手動設定して正しく動くようにしてください。
</p></item>
<item><p><!--
Some systems (including previous Debian versions) use
xmodmap to arrange for both <tt><--</tt> and Delete
to generate KB_Delete. We can change the behavior
of their X clients via the same X resources that we
use to do it for our own, or have our clients be
configured via their resources when things are the
other way around. On displays configured like this
Delete will not work, but <tt><--</tt>
will.-->
一部のシステム (以前の Debian の版もそうでした) では
<tt><--</tt> と Delete キーが Delete キーイベントを起こすよう
xmodmap で設定しています。私たちは、 クライアントに対して同一の X リソースで私たちの望む設定を行い、
また各クライアントが別の設定を望んだときに個別のリソース
で設定できるように上記のように変更しています。xmodmap
を使ったシステムでは Delete はたぶん動きませんが、
<tt><--</tt> の方は正しく動作します。</p></item>
<item><p><!--
Some operating systems have different kdch1 settings
in their terminfo for xterm and others. On these
systems the Delete key will not work correctly when
you log in from a system conforming to our policy, but
<tt><--</tt> will.-->
一部の OS では xterm などの端末設定の terminfo 中の kdch1
に別の設定がされています。このようなシステムに、
このポリシーに従ったシステムからログインした場合には Delete
キーは正常動作しませんが、<tt><--</tt> は正しく動作します。
</p></item>
</list>
</p>
</sect>
<sect>
<!-- <heading>Environment variables</heading>-->
<heading>環境変数</heading>
<p><!--
A program must not depend on environment variables to get
reasonable defaults. (That's because these environment
variables would have to be set in a system-wide
configuration file like /etc/profile, which is not supported
by all shells.)-->
プログラムは妥当な結果を得るために特定の環境変数の設定に依存するものであってはいけません。
これはこのような環境変数はシステム全体に影響を及ぼす
/etc/profile のような設定ファイルで設定しなければなりませんが、このような設定ファイルがすべてのシェルでサポートされているわけではないためです。
</p>
<p><!--
If a program usually depend on environment variables for its
configuration, the program should be changed to fall back to
a reasonable default configuration if these environment
variables are not present. If this cannot be done easily
(e.g., if the source code of a non-free program is not
available), the program must be replaced by a small
`wrapper' shell script which sets the environment variables
and calls the original program.-->
プログラムが通常環境変数の設定に依存する場合、環境変数が設定されていなかった場合に妥当な既定値を使うように修正するようにすべきです。
これがもし容易に行えないようなら (例えば non-free
プログラムでソースコードがない場合など)
プログラムは環境変数を設定して元のプログラムを呼び出すようなラッパスクリプトに置き換えておかなければいけません。
</p>
<p><!--
Here is an example of a wrapper script for this purpose:-->
この目的のためのラッパスクリプトを次に示します。
<example>
#!/bin/sh
BAR=${BAR:-/var/lib/fubar}
export BAR
exec /usr/lib/foo/foo "$@"
</example></p>
<p><!--
Furthermore, as <tt>/etc/profile</tt> is a configuration
file of the <prgn>base-files</prgn> package, other package must
not put any environment variables or other commands into that
file.-->
更に <tt>/etc/profile</tt> は <prgn>base-files</prgn>
パッケージの設定ファイルですので、他のプログラムはこのファイルに環境変数やそのほかのコマンドの設定を追加してはいけません。
</p>
</sect>
</chapt>
<chapt>
<!-- <heading>Files</heading> -->
<heading>ファイル</heading>
<sect>
<!-- <heading>Binaries</heading> -->
<heading>バイナリファイル</heading>
<p>
<!-- Two different packages must not 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 must 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 by default 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>-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>
<!-- Debugging symbols are useful for error diagnosis,
investigation of core dumps (which may be submitted by users
in bug reports), or testing and developing the
software. Therefore it is recommended to support building
the package with debugging information through the following
interface: If the environment variable
<tt>DEB_BUILD_OPTIONS</tt> contains the string
<tt>debug</tt>, compile the software with debugging
information (usually this involves adding the <tt>-g</tt>
flag to <tt>CFLAGS</tt>). This allows the generation of a
build tree with debugging information. If the environment
variable <tt>DEB_BUILD_OPTIONS</tt> contains the string
<tt>nostrip</tt>, do not strip the files at installation
time. This allows one to generate a package with debugging
information included. The following makefile snippet is only
an example of how one may test for either condition:-->
デバッグ情報はエラー解析やコアダンプ (バグレポートに添付してユーザから送られてきたもの)
の分析や、ソフトウェアのテストや開発に役に立ちます。
このため、次のインターフェースでデバッグ情報を含んだパッケージのビルドをサポートしておくことを推奨します:
環境変数 <tt>DEB_BUILD_OPTIONS</tt> が文字列
<tt>debug</tt> を含んでいた場合、ソフトウェアをデバッグ情報付きで
(通常は <tt>CFLAGS</tt> に <tt>-g</tt> フラグを含めることを意味します)
コンパイルしてください。これにより、デバッグ情報付きのビルドツリーの世代管理ができます。
また、環境変数
<tt>DEB_BUILD_OPTIONS</tt> が文字列 <tt>nostrip</tt>
を含んでいた場合、インストール時にファイルに strip
を行わないようにしてください。これにより、デバッグ情報を含めたパッケージを作成できます。
次に示す makefile の断片はこの両方の条件を試す例の部分だけを示したものです
<footnote>
<p><!--
Rationale: Building by default with -g causes more
wasted CPU cycles since the information is stripped away
anyway. The package can by default build without -g if
it also provides a mechanism to easily be rebuilt with
debugging information. This can be done by providing a
"build-debug" make target, or allowing the user to
specify "DEB_BUILD_OPTIONS=debug" in the environment while
compiling that package.-->
原則の解説: 既定値として -g を使うのは単に CPU 時間の無駄使いです。
というのはデバッグに必要な情報はどちらにせよ strip されてしまっていますから。
パッケージが簡単にデバッグ情報付きでビルドし直せるようにすれば既定値としては
-g なしでビルドすることにしておくことができます。
これは make ターゲットとして
"build-debug" ターゲットを与えるか、パッケージのコンパイルの際に
"DEB_BUILD_OPTIONS=debug" と環境変数を指定しておけばデバッグ情報付きのビルドが行えるようになります。
</p>
<p><!-- Now this has several added benefits:-->
これには他の利点もあって、
<list>
<item>
<p><!--
It is actually easier to build debugging bins and
libraries this way (no more editing debian/rules
or similar) since it provides a documented way of
getting this type of build.-->
まずデバッグ用のバイナリやライブラリをこのやり方で作ることができる
(つまり、debian/rules を編集する必要は最早無い)
ことです。何となれば、このやり方はまさにデバッグ用のバイナリを作るために規定された方法に沿ったやり方となっているからです。
</p>
</item>
<item>
<p><!--
There will be much less wasted CPU time for the
autobuilders since not having debugging
information (and hence also not having to strip
it) will increase the speed of compiles. This
skips an entire pass of the compiler. -->
自動ビルド時に CPU 時間をずっと節約できます。
これはデバッグ情報を含めない (したがってそれを strip もしない)
ことはコンパイル速度を改善するからです。
これはコンパイラの手順を丸ごと一つ省くことになりますので。
</p>
</item>
</list>
</p>
</footnote>。
</p>
<p>
<example>
CFLAGS = -O2 -Wall
INSTALL = install
INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644
INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755
INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755
INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755
ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS)))
CFLAGS += -g
endif
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
</example>
<!-- Please note that the above example is merely informative,
and is not a policy mandate. You may have to massage this
example in order to make it work for your package.-->
上記の例は単なる参考のためのもので、policy で従うべき内容を示したものではないことに注意してください。
あなたのパッケージでこの例が動作するようにするためにはあちこち手直しする必要があるでしょう。
</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) will
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 will need to be compiled twice.-->
全てのライブラリは共有ライブラリ版の lib パッケージとスタティックライブラリ版の
lib-dev パッケージを用意しなければいけません。
共有ライブラリバージョンは <tt>-fPIC</tt> オプション付きでコンパイルし、
スタティックライブラリバージョンではそうしてはいけません。
言い替えれば、<tt>*.c</tt> は二度コンパイルされる必要があることになります。
</p>
<p>
<!-- You must 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 should
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>
<!-- You must 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> です。
(.so ファイル名 (<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 should also have 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>
に対して依存関係を指定します。.so ファイル名 (<var>soname</var>) を変更して
旧ライブラリから新ライブラリへの移行期間中に両方のバージョンをインストールしておくこともできます。
</p>
<p>
<!-- If your package has some run-time support programs which
use the shared library you must not 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.
-->
パッケージが、共有ライブラリを使用する場合の実行時のサポートプログラムをもつ場合、
共有ライブラリパッケージにそれらを含めてはいけません。
そのようにしてしまうと、ファイル名の衝突を避けることなく、複数のバージョンの共有ライブラリをインストールすることができません。
この場合には代わりに、実行時のサポートのための三番目のパッケージ
(そのパッケージ名は通常、
<tt><var>libraryname</var>-runtime</tt> とします。.so
ファイル名 (<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).-->
同じソースツリーから複数の共有ライブラリをビルドする場合、
それらをまとめて一つの共有ライブラリパッケージにすることができます。
そのときにはこの集合ライブラリの複数のバージョンをインストールした場合にファイル名の衝突が起きないように、
.so ファイル名 (<var>soname</var>) の変更は、このライブラリ集合の各ライブラリに対して一括して実施するようにしてください。
</p>
<p>
<!-- You should follow the directions in the <em>Debian Packaging
Manual</em> (or other documentation of the Debian
packaging tools) for putting the shared library in its
package, and you must include a <tt>shlibs</tt> control area
file with details of the dependencies for packages which use
the library.</p>-->
パッケージ中に共有ライブラリを含むに当たっては
<em>Debian パッケージングマニュアル</em> (または Debian パッケージングツールのその他の説明文書)
の指示に従うべきで、このライブラリを使うパッケージのための依存関係の詳細を記載した
<tt>shlibs</tt>
制御領域に置くファイルを含めておかなければなりません。
</p>
<p>
<!-- Shared libraries should not be installed
executable, since <prgn>ld.so</prgn> does not require this
and trying to execute a shared library results in a core
dump.-->
共有ライブラリに実行属性を付けてインストールしてはいけません。
<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 should 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>コマンドの終了ステータスを明示的に調べてエラーを検出すべきです。
</p>
<p>
<!-- The standard shell interpreter `<tt>/bin/sh</tt>' can be a
symbolic link to any POSIX compatible shell if <tt>echo -n</tt>
does not generate a newline. -->
標準のシェルインタープリタは `<tt>/bin/sh</tt>' で、これは
<tt>echo -n</tt>で改行を挿入することがないような POSIX 互換なシェルのどれかへのシンボリックリンクです
<footnote>
<p><!--
Debian policy specifies POSIX behavior for /bin/sh, but
echo -n has widespread use in the Linux community
(including especially debian policy, the linux kernel
source, many debian scripts, etc.). This echo -n
mechanism is valid but not required under POSIX, hence
this explicit addition. Also, rumour has it that this
shall be mandated under the LSB anyway.-->
Debian ポリシーでは /bin/sh は POSIX 準拠の動作とすることを規定しています。
一方 echo -n は Linux コミュニティで広く使用されています
(debian policy や、linux カーネルソースや、多くの debian
スクリプト中にも見られます)。POSIX 規格では echo -n
の動作は規定されてはいますが、
この規定への準拠は必須とはされていないため、ここで明示的に追加します。
また、噂では LSB ではどちらにせよ必須となるとのことですので。
</p>
</footnote>。
<!--Thus, shell
scripts specifying `<tt>/bin/sh</tt>' as interpreter should
only use POSIX features. If a script requires non-POSIX
features from the shell interpreter, the appropriate shell
must 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 規定の機能だけを使うべきです。スクリプトで POSIX
に規定されていない機能をインタープリタに期待する場合には、
適切なシェルを最初に指定 (例えば `<tt>#!/bin/bash</tt>' のように)
して、パッケージからそのシェルに対して依存関係を与えてください
(そのシェルパッケージが `Essential' 扱いになっている、
例えば <prgn>bash</prgn> のような場合は依存関係の指定は不要です)。
</p>
<p>
<!-- You may wish to 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><p>
訳注：日本語訳はとりあえず <ftpsite>ftp.sra.or.jp</ftpsite> の
<ftppath>/pub/news/fj.archives.documents/csh-whynot-jp</ftppath>
にあります。
<!-- ほかにもあるとは思うけど、すぐには見つからなかった。--></p>
</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>
<!-- Package must not 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 must 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/ttyS*</tt>. Programs using the old
<tt>/dev/cu*</tt> devices should be changed to use
<tt>/dev/ttyS*</tt>.-->
Debian ではシリアルデバイスファイル名に <tt>/dev/ttyS*</tt>
を使います。昔の <tt>/dev/cu*</tt> を使っているプログラムは
<tt>/dev/ttyS*</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
must 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 package 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 must 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 only 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><!--
In order to ensure that local changes are preserved
correctly, no package may contain or make hard links to
conffiles.-->
パッケージの conffile にハードリンクを張ることは、ローカルで加えた変更を正しく残せなくなるため、許されていません
<footnote>
<p><!--
Rationale: There are two problems with hard links.
The first is that some editors break the link while
editing one of the files, so that the two files may
unwittingly become different. The second is that
<prgn>dpkg</prgn> might break the hard link while
upgrading <tt>conffile</tt>s.-->
原則の解説: ハードリンクには二つの問題があります。まず第一にそのうちの一つのファイルを編集する際にリンクを切ってしまうエディタがあり、
知らない間に二つのファイルが別なものになってしまうことがあります。
第二に、<prgn>dpkg</prgn>
が <tt>conffile</tt> のアップグレード時にリンクを切ってしまうかもしれません。
</p>
</footnote>。
</p>
<p>
<!-- The other way to do it is 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 are not required 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/<package></tt> or
<tt>/usr/lib/<package></tt> with a symbolic link
from <tt>/usr/share/doc/<package>/examples</tt>
if they are examples, 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/<package></tt>
または <tt>/usr/lib/<package></tt> に置き、
それが例なら <tt>/usr/share/doc/<package>/examples</tt>
へシンボリックリンクを作成してください。また、通常の
<prgn>dpkg</prgn> で処理するファイルにして (すなわち、
<tt>conffile</tt> では<em>無いようにする</em>) ください。
</p>
<p>
<!-- These two styles of configuration file handling must
not be mixed, for that way lies madness:
<prgn>dpkg</prgn> will ask about overwriting the file
every time the package is upgraded.-->
これまで説明してきた設定ファイルの扱いの手法は混在させてはいけません。
それは、はちゃめちゃへの一本道です。
<prgn>dpkg</prgn> がパッケージをアップグレードする際に毎回ファイルを上書きするかどうか問い合わせてくるようになり、頭を掻きむしることになります。
</p>
</sect1>
<sect1>
<!-- <heading>Sharing configuration files</heading>-->
<heading>設定ファイルの共用</heading>
<p><!--
Packages which specify the same file as
`<tt>conffile</tt>' must be tagged as <em>conflicting</em>
with each other.-->
同じファイルを
<tt>conffile</tt> として指定しているパッケージ間は
<em>競合 (conflict)</em> していると指定しなければいけません。
</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 must 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 be 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
may 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 を集中管理する logrotate プログラムを使う方法です。
このプログラムは設定ファイル (<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>
<!-- Log files must be 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>
<!-- Log files should be 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 should 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>
<!-- You must 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, as in
this case you need a statically allocated id).-->
パッケージのために新しいユーザまたはグループを作成する必要がある場合、二つの方法があります。
第一の方法は、このユーザまたはグループを所有者としてバイナリパッケージの所定のファイルを作成します。
または、バイナリに単なる名前ではなくユーザあるいはグループ ID をコンパイル時に埋め込むようにもできます
(この方法は静的に割り当てられた ID
が必要となるため、可能な限り避けるべきです)。
</p>
<p>
<!-- If you need a statically allocated id, you must ask for a
user or group id from the base system
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).-->
静的に割り当てられた id が必要な場合、base システムの管理者にユーザあるいはグループ
ID の割り当てを求めます。割り当てられるまでパッケージをリリースすることはできません。
このようなユーザやグループが割り当てられたらならば、パッケージは当該
ID を
<tt>/etc/passwd</tt> ないしは <tt>/etc/group</tt>
に含むような base システムの特定以降のバージョンに依存するようにするか、パッケージ中の pre- または post-inst
スクリプト等で割り当てられた
ID を (<tt>adduser</tt> などを使って) 自分で作成するようにしてください。
postinst で行うほうが、可能ならばより良いやり方です。
</p>
<p>
<!-- On the other hand, the program might be 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 should 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>
<chapt id="customized-programs">
<!-- <heading>Customized programs</heading> -->
<heading>プログラムの個々の設定</heading>
<sect id="arch-spec">
<!-- <heading>Architecture specification strings</heading> -->
<heading>アーキテクチャ指定のための文字列</heading>
<p>
<!-- If a program needs to specify an <em>architecture specification
string</em> in some place, the following format has to be used: -->
もしプログラムに<em>アーキテクチャを指定するための文字列</em>が必要な場合には次の書式に従わなければなりません。
<example>
<arch>-<os>
</example>
<!-- where `<arch>' is one of the following: i386, alpha, arm,
m68k, powerpc, sparc and `<os>' is one of: linux, gnu. Use
of <em>gnu</em> in this string is reserved for the GNU/Hurd
operating system.-->
ここで `<arch>' は i386、alpha、arm、m68k、powerpc、sparc
のいずれかです。また `<os>' は linux か gnu のどちらかになります。
ここでの <em>gnu</em> は GNU/Hurd オペレーティングシステムのために予約されています。
</p>
<p>
<!-- Note, that we don't want to use `<arch>-debian-linux'
to apply to the rule `architecture-vendor-os' since this
would make our programs incompatible to other Linux
distributions. Also note, that we don't use
`<arch>-unknown-linux', since the `unknown' does not
look very good.-->
私たちは、他の Linux ディストリビューションとの互換性をなくすので、
`architecture-vendor-os' の場所に `<arch>-debian-linux'
を使わないようにしています。また、`unknown' は見苦しいので、
`<arch>-unknown-linux' も使いません。
</p></sect>
<sect>
<!-- <heading>Daemons</heading>-->
<heading>デーモン類</heading>
<p>
<!-- The configuration files <tt>/etc/services</tt>,
<tt>/etc/protocols</tt>, and <tt>/etc/rpc</tt> are managed
by the <prgn>netbase</prgn> package and may not be modified
by other packages.-->
設定ファイルのうち、<tt>/etc/services</tt>、
<tt>/etc/protocols</tt> と <tt>/etc/rpc</tt> は
<prgn>netbase</prgn> パッケージで管理されます。ほかのパッケージはこれらに修正を加えてはいけません。
</p>
<p>
<!-- If a package requires a new entry in one of these files, the
maintainer should get in contact with the
<prgn>netbase</prgn> maintainer, who will add the entries
and release a new version of the <prgn>netbase</prgn>
package.-->
パッケージの都合でこれらのファイルに新エントリが必要な場合には、
メンテナは <prgn>netbase</prgn> パッケージのメンテナに連絡を取って、エントリを加えた新しい
<prgn>netbase</prgn> パッケージをリリースしてもらうべきです。
</p>
<p>
<!-- The configuration file <tt>/etc/inetd.conf</tt> must not be
modified by the package's scripts except via the
<prgn>update-inetd</prgn> script or the
<prgn>DebianNet.pm</prgn> Perl module.-->
設定ファイル <tt>/etc/inetd.conf</tt> は <prgn>update-inetd</prgn>
スクリプトか、<prgn>DebianNet.pm</prgn> Perl モジュールを介さずにパッケージスクリプトから変更してはいけません。
</p>
<p>
<!-- If a package wants to install an example entry into
<tt>/etc/inetd.conf</tt>, the entry must be preceded with
exactly one hash character (<tt>#</tt>). Such lines are
treated as `commented out by user' by the
<prgn>update-inetd</prgn> script and are not changed or
activated during a package updates.-->
パッケージから <tt>/etc/inetd.conf</tt> に設定例としてエントリを挿入したい場合には、対象となるエントリは最初に一つだけのコメントキャラクタ
(<tt>#</tt>) を置いてください。
そのように書かれた行は <prgn>update-inetd</prgn> からは『ユーザによってコメントアウトされた行
と扱われ、変更されたりパッケージ更新時に有効化されたりすることはありません。
</p></sect>
<sect>
<!-- <heading>Using pseudo-ttys and modifying wtmp, utmp and lastlog</heading> -->
<heading>仮想 tty の使用、wtmp、utmp、lastlog 等の更新</heading>
<p>
<!-- Some programs need to create pseudo-ttys. This should be done
using Unix98 ptys if the C library supports it. The resulting
program must not be installed setuid root, unless that
is required for other functionality. -->
一部のプログラムでは仮想 tty の作成が必要になります。これは C
ライブラリのサポートがあれば Unix98 pty
を使うことで実現できます。このようなプログラムは、ほかの機能実現のために必要でなければ、(仮想 tty の作成のためだけに)
root に setuid してはいけません。
</p>
<p>
<!-- The files <tt>/var/run/utmp</tt>, <tt>/var/log/wtmp</tt> and
<tt>/var/log/lastlog</tt> must be installed writeable by
group utmp. Programs who need to modify those files must
be installed setgid utmp. -->
<tt>/var/run/utmp</tt>、<tt>/var/log/wtmp</tt> と
<tt>/var/log/lastlog</tt> はグループ utmp
に対して書き込み可能なようにインストールしなければなりません。
また、これらのファイルに書く必要があるプログラムは utmp に setgid してインストールしてください。
</p>
</sect>
<sect>
<!-- <heading>Editors and pagers</heading> -->
<heading>エディタとページャ</heading>
<p>
<!-- Some programs have the ability to launch an editor or pager
program to edit or display a text document. Since there are
lots of different editors and pagers available in the Debian
distribution, the system administrator and each user should
have the possibility to choose his/her preferred editor and
pager.-->
エディタやページャを、テキスト文書の編集や表示に使うプログラムがあります。
Debian ディストリビューションで利用できるエディタやページャにはたくさんの種類があるので、システム管理者とユーザが好みのエディタとページャを選択できるようにすべきです。
</p>
<p>
<!-- In addition, every program should choose a good default
editor/pager if none is selected by the user or system
administrator.-->
さらに、各々のプログラムは、ユーザまたはシステム管理者が特定の選択を行っていない場合には、ふさわしいデフォルトのエディタとページャを選択すべきです。
</p>
<p>
<!-- Thus, every program that launches an editor or pager must
use the EDITOR or PAGER environment variables to determine
the editor/pager the user wants to get started. If these
variables are not set, the programs <tt>/usr/bin/editor</tt>
and <tt>/usr/bin/pager</tt> should be used, respectively.-->
上記の理由で、エディタやページャを利用する各プログラムは、
EDITOR および PAGER 環境変数を利用してエディタとページャを決めなければいけません。
これらの値が設定されていなければ、プログラムは
<tt>/usr/bin/editor</tt> と <tt>/usr/bin/pager</tt>
を利用するようにすべきです。
</p>
<p>
<!-- These two files are managed through `alternatives.' That is,
every package providing an editor or pager must call the
<prgn>update-alternatives</prgn> script to register these
programs.-->
これら2つのプログラムは代替パッケージ機能 (alternatives) を通して管理されています。
すなわち、エディタとページャ機能を提供する各プログラムは
`update-alternatives' スクリプトを使って自分を登録しておかなければいけません。
</p>
<p>
<!-- If it is very hard to adapt a program to make us of the
EDITOR and PAGER variable, that program may be configured
to use <tt>/usr/bin/sensible-editor</tt> and
<tt>/usr/bin/sensible-pager</tt> as editor or pager program,
respectively. These are two scripts provided in the Debian
base system that check the EDITOR and PAGER variables and
launch the appropriate program or falls back to
<tt>/usr/bin/editor</tt> and <tt>/usr/bin/pager</tt>,
automatically.-->
EDITOR、PAGER 環境変数を参照して動作するようプログラムを修正するのが困難な場合は、
<tt>/usr/bin/sensible-editor</tt> と
<tt>/usr/bin/sensible-pager</tt>
をエディタ、ページャのプログラムとして使うように設定してもかまいません。
これらは Debian 基本システムで提供されるスクリプトで、自動的に
EDITOR と PAGER
の各環境変数を調べて適当なプログラムを起動するか、それに失敗すれば
<tt>/usr/bin/editor</tt> や
<tt>/usr/bin/pager</tt> を起動します。</p>
<p>
<!-- A program may also use the VISUAL environment variable to
determine the user's choice of editor. If it exists, it
should take precedence over EDITOR. This is in fact what
<tt>/usr/bin/sensible-editor</tt> does. -->
プログラムはユーザの好みのエディタを判断するのに VISUAL
環境変数を用いてもかまいません。この環境変数が定義されているならば、
EDITOR による設定より優先させてください。
<tt>/usr/bin/sensible-editor</tt> でもこの処理が行われています。
</p>
<p>
<!-- It is not required for a package to depend on
`editor' and `pager', nor is it required for a package to
provide such virtual packages.-->
パッケージは `editor' や `pager' に依存する必要がなく
<footnote>
<p>
<!-- The Debian base system already provides an editor and
a pager program, -->
Debian ベースシステムが `editor' と `pager' プログラムを提供しています。
</p>
</footnote>
、パッケージからこの二つの仮想パッケージを提供する必要もありません。
</p></sect>
<sect id="web-appl">
<!-- <heading>Web servers and applications</heading> -->
<heading>Web サーバとアプリケーション</heading>
<p>
<!-- This section describes the locations and URLs that should
be used by all web servers and web application in the Debian
system.-->
この節では Debian システムでの全ての web サーバと web
アプリケーションから利用すべき場所 (ディレクトリ) といくつかの URL
を説明します。
</p>
<p>
<enumlist>
<item>
<p><!-- Cgi-bin executable files are installed in the
directory -->
cgi-bin 実行ファイルは次のディレクトリにインストールしてください。
<example>
/usr/lib/cgi-bin/<cgi-bin-name>
</example>
<!-- and should referred to as -->
そして次のようにして参照できるように設定するべきです。
<example>
http://localhost/cgi-bin/<cgi-bin-name>
</example></p></item>
<!-- <item><p>Access to html documents</p> -->
<item><p>HTML 文書へのアクセス</p>
<p>
<!-- Html documents for a package are stored in
<tt>/usr/share/doc/<var>package</var></tt> but should
be accessed via symlinks as
<tt>/usr/doc/<var>package</var></tt><footnote> for
backward compatibility, see <ref id="usrdoc"></footnote>
and can be referred to as -->
各パッケージの HTML 形式の文書は
<tt>/usr/share/doc/<var>package</var></tt> に置きます。
ただし、<tt>/usr/doc/<var>package</var></tt> からシンボリックリンクでアクセスできるように
<footnote> 以前との互換性を維持するためです。<ref id="usrdoc">
の項を参照ください。</footnote>
してください。
また、次のようにして参照することができるようにしてください。
<example>
http://localhost/doc/<package>/<filename>
</example></p></item>
<!-- <item><p>Web Document Root</p> -->
<item><p>Web 文書ルートディレクトリ</p>
<p>
<!-- Web Applications should try to avoid storing files in
the Web Document Root. Instead they should use the
/usr/share/doc/<package> directory for documents and
register the Web Application via the menu package. If
access to the web-root is unavoidable then use -->
web アプリケーションは Web 文書ルートディレクトリにファイルを置かないように努めてください。
代わりに、文書類には
<tt>/usr/share/doc/<package></tt> ディレクトリを使い、menu
パッケージ経由で web アプリケーションとして登録するべきです。
どうしても Web 文書ルートディレクトリを使わざるをえない場合には、
<example>
/var/www
</example>
を Web 文書ルートディレクトリとして使ってください。
<!-- as the Document Root. This might be just a
symbolic link to the location where the sysadmin has
put the real document root.-->
これは、システム管理者が実際に Document Root へ設定した場所へのシンボリックリンクでも良いでしょう。
</p>
</item>
</enumlist>
</p>
</sect>
<sect id="mail-transport-agents">
<!-- <heading>Mail transport, delivery and user agents</heading>-->
<heading>メール配送、配信、ユーザエージェント</heading>
<p>
<!-- Debian packages which process electronic mail, whether
mail-user-agents (MUAs) or mail-transport-agents (MTAs),
<em>must</em> make sure that they are compatible with the
configuration decisions below. Failure to do this may
result in lost mail, broken <tt>From:</tt> lines, and other
serious brain damage!-->
電子メールを扱う Debian パッケージは、それがメールユーザエージェント
(mail-user-agents、MUA) またはメール配送エージェント
(mail-transport-agents、MTA) のいずれであれ、下記の設定基準に準拠していることを確認してください。
これが満たされない場合はメールを失ったり、<tt>From:</tt>
行がおかしかったり、他の流血の惨事を引き起こすかもしれません。
</p>
<p><!--
The mail spool is <tt>/var/spool/mail</tt> and the interface
The mail spool is <tt>/var/mail</tt> and the interface
to send a mail message is <tt>/usr/sbin/sendmail</tt> (as
per the FHS). On older systems, the mail spool may be
physically located in /var/spool/mail, but all access to the
mail spool should be via the /var/mail symlink. The mail
spool is part of the base system and not part of the MTA
package.
</p>-->
per the FHS). The mail spool is part of the base system
and not part of the MTA package.
FHS に記載の通り、メールスプールは <tt>/var/mail</tt> であり、メールを送るインターフェースプログラムは
<tt>/usr/sbin/sendmail</tt> です。
以前のシステムではメールスプールは物理的に /var/spool/mail
に置かれているが、すべてのメールスプールのアクセスは /var/mail
シンボリックリンクを介して行っていた場合もありました。
メールスプールは base システムの
一部で、MTA パッケージの一部ではありません。</p>
<p>
<!-- All Debian MUAs, MTAs, MDAs and other mailbox accessing
programs (like IMAP daemons) must lock the mailbox in an
NFS-safe way. This means that <tt>fcntl()</tt> locking must
be combined with dot locking. To avoid dead locks, a
program should use <tt>fcntl()</tt> first and dot locking
after this or alternatively implement the two locking
methods in a non blocking way-->
Debian システムの MUA、MTA、MDA およびその他のメールボックスを参照するプログラム
(IMAP デーモンなど) はすべて NFS 環境下で安全な方法を使ってファイルロックを行わなければいけません。
すなわち、<tt>fcntl()</tt>
によるロックはドットファイルによるロックと併用しなければなりません。
デッドロックを避けるため、プログラムではまず
<tt>fcntl()</tt> を使って、次にドットファイルロックを使うか、二つのロックをブロックしないやり方
<footnote>
<p>
<!-- If it is not possible to establish both locks, the
system shouldn't wait for the second lock to be
established, but remove the first lock, wait a (random)
time, and start over locking again.-->
二つのロックが取得できない場合には、システムは二つ目のロックが取得できるまで待つのではなく、最初のロックを解放して、乱数で決定した時間だけ待ち、再度ロックの取得をおこなうようにしてください。
</p>
</footnote>
で使うべきです。<!--. Using the functions <tt>maillock</tt> and
<tt>mailunlock</tt> provided by the
<tt>liblockfile*</tt><footnote>
<p>
<tt>liblockfile</tt> version >>1.01</p>
</footnote> packages is the recommended way to realize this. -->
<tt>liblockfile*</tt>パッケージ <footnote>
<p>
<tt>liblockfile</tt> version >>1.01</p>
</footnote>
に含まれる <tt>maillock</tt> と <tt>mailunlock</tt>
を使うのが上記を実現するお勧めのやり方です。
</p>
<p>
<!-- Mailboxes are generally 660 <tt><var>user</var>.mail</tt>
unless the user has chosen otherwise. A MUA may remove a
mailbox (unless it has nonstandard permissions) in which
case the MTA or another MUA must recreate it if needed.
Mailboxes must be writable by group mail.-->
メールボックスはユーザが他を選ばない限り、通常は 660
<tt><var>user</var>.mail</tt> のパーミッションです。
MUA は必要に応じてメールボックスを削除してもかまいません
(特殊なパーミッションになっていない場合)。
その場合には MTA や ほかの MUA
は必要に応じてメールボックスを再作成できなければなりません。
メールボックスは mail グループから書き込み可能でなければなりません。
</p>
<p>
<!-- The mail spool is 2775 <tt>root.mail</tt>, and MUAs should
be setgid mail to do the locking mentioned above (and
must obviously avoid accessing other users' mailboxes
using this privilege).-->
メールスプールディレクトリは 2775 <tt>root.mail</tt> で、MUA
は上記のロックを取得するため mail に setgid されているべきです。
当然、この特権を使って他の人のメールボックスにアクセスすることは避けなければなりません。
</p>
<p>
<tt>/etc/aliases</tt> <!-- is the source file for the system mail
aliases (e.g., postmaster, usenet, etc.)--it is the one
which the sysadmin and <tt>postinst</tt> scripts may edit.
After <tt>/etc/aliases</tt> is edited the program or human
editing it must call <prgn>newaliases</prgn>. All MTA
packages must come with a <prgn>newaliases</prgn> program,
even if it does nothing, but older MTA packages do not do
this so programs should not fail if <prgn>newaliases</prgn>
cannot be found.-->
はシステムのメールエイリアス (例えば、postmaster、usenetなど)
が記載されたソースファイルで、システム管理者と <tt>postinst</tt>
スクリプトからの編集が許されています。<tt>/etc/aliases</tt> をプログラムあるいは人手で編集した後には
<prgn>newaliases</prgn> コマンドを呼び出さなければなりません。
全ての MTA パッケージは (実際には何もしないものであったとしても)
<prgn>newaliases</prgn> プログラムを同梱していなければなりませんが
古い MTA パッケージにはこれがないものもありますので、たとえ
<prgn>newaliases</prgn> が見つからなくてもプログラムが落ちな
いようにしなければなりません。</p>
<p>
<!-- The convention of writing <tt>forward to
<var>address</var></tt> in the mailbox itself is not
supported. Use a <tt>.forward</tt> file instead.-->
メールボックスに転送先のアドレスを書く仕組みはサポートされていません。
代わりに <tt>.forward</tt> ファイルを使ってください。</p>
<p>
<!-- The <prgn>rmail</prgn> program used by UUCP
for incoming mail should be <tt>/usr/sbin/rmail</tt>
Likewise, <prgn>rsmtp</prgn>, for receiving
batch-SMTP-over-UUCP, should be in <tt>/usr/sbin/rsmtp</tt> if it
is supported.-->
UUCPで使われる <prgn>rmail</prgn> プログラムは
<tt>/usr/sbin/rmail</tt> にしてください。同様に
batch-SMTP-over-UUCP を受け取る <prgn>rsmtp</prgn>
は、サポートされている場合は、<tt>/usr/sbin/rsmtp</tt> に置くべきです。</p>
<p>
<!-- If you need to know what name to use (for example) on
outgoing news and mail messages which are generated locally,
you should use the file <tt>/etc/mailname</tt>. It will
contain the portion after the username and <tt>@</tt> (at)
sign for email addresses of users on the machine (followed
by a newline).-->
ローカルで作成された外部へのニュースやメールのメッセージに対して使う名前 (など) が必要な場合は、
<tt>/etc/mailname</tt> ファイルを使ってください。
そのファイル中にはそのマシンのユーザのメールアドレスとして、ユーザ名と
<tt>@</tt> の後に続く部分が書かれています (最後に改行が入ります)。
</p>
<p>
<!-- A package should check for the existence of this file. If
it exists it should use it without comment. (An MTA's
prompting configuration script may wish to prompt the user
even if it finds this file exists.) If it does not exist it
should prompt the user for the value and store it in
<tt>/etc/mailname</tt> as well as using it in the package's
configuration. The prompt should make it clear that the
name will not just be used by that package. For example, in
this situation the INN package says: -->
各パッケージはこのファイルの存在をチェックしなければなりません。
そのファイルが存在すればそれ以上の質問なしにそのファイルを使ってください
(MTAの設定スクリプト中では、このファイルが存在している場合にこれを使うかどうかの質問をしてもかまいません)。
このファイルが存在しなければ、パッケージの設定中にユーザに
<tt>/etc/mailname</tt> に書くべき内容を問い合わせ、その内容を書いてください。
ここでの問い合わせでは、今問い合わせている名前は、ここで問い合わせを行ったプログラムだけで使うものではないことがはっきり分かるように質問を行うよう留意してください。
例えば、INN パッケージでは次のように質問しています。
<example>
Please enter the `mail name' of your system. This is the
hostname portion of the address to be shown on outgoing
news and mail messages. The default is
<var>syshostname</var>, your system's host name. Mail
name [`<var>syshostname</var>']:
</example>
<!-- そのままに(一応)してあります。INN ってここ日本語にな
ってたんでしたっけ -->
<!-- where <var>syshostname</var> is the output of <tt>hostname
--fqdn</tt>.-->
ここで <var>syshostname</var> は <tt>hostname --fqdn</tt>
の出力結果です。
</p></sect>
<sect>
<!-- <heading>News system configuration</heading> -->
<heading>ニュースシステムの設定</heading>
<p>
<!-- All the configuration files related to the NNTP (news)
servers and clients should be located under
<tt>/etc/news</tt>.-->
NNTP (ニュース) サーバやクライアントに関係した設定ファイルはすべて
<tt>/etc/news</tt> 以下に置かなければなりません。</p>
<p>
<!-- There are some configuration issues that apply to a number
of news clients and server packages on the machine. These
are: -->
一台のマシン上での複数のニュースクライアントやサーバパッケージで用いる設定上の留意点があります。
それらを次に説明します。
<taglist>
<tag>/etc/news/organization</tag>
<item><p><!-- A string which should appear as the
organization header for all messages posted
by NNTP clients on the machine-->
当該マシンの NNTP クライアントから投稿された記事の
Organization ヘッダに現れる (べき) 文字列を格納します。
</p></item>
<tag>/etc/news/server</tag>
<item><p><!-- Contains the FQDN of the upstream NNTP
server, or localhost if the local machine is
an NNTP server.-->
上流の NNTP サーバの FQDN が書かれています。
自分自身がニュースサーバでもある場合には localhost
と書かれています。</p></item>
</taglist>
<!-- Other global files may be added as required for cross-package
news configuration.-->
そのほかのパッケージ間で使用するニュース関連の設定は必要に応じて適宜追加してください。
</p></sect>
<sect>
<!-- <heading>Programs for the X Window System</heading> -->
<heading>X ウィンドウシステム用のプログラム</heading>
<p> <!--
<em>Programs that may be configured with support for the X Window
System</em> must be configured to do so and must declare any
package dependencies necessary to satisfy their runtime
requirements when using the X Window System, unless the package
in question is of standard or higher priority, in which case
X-specific binaries may be split into a separate package, or
alternative versions of the package with X support may be
provided.-->
<em>X ウィンドウシステム向けサポートを行うよう構成可能なプログラムは</em>
X ウィンドウシステムのサポートを含むように構成しなければいけません。
また、このパッケージが標準またはより高いプライオリティでインストールされるものでない場合には、X
ウィンドウシステム下で使用する際の実行時の必要性を満たすようにパッケージ依存関係を宣言しなければいけません。
対象となるパッケージが
standard またはより高いプライオリティでインストールされるものである場合には、
X 関連のパッケージを別パッケージに分離してもかまいませんし、また
X をサポートした別バージョンのパッケージを作成してもかまいません。
</p>
<p><!--
<em>Packages which provide an X server</em> that, directly or
indirectly, communicates with real input and display hardware
should declare in their control data that they provide the
virtual package <tt>xserver</tt>.-->
<em>X サーバを提供するパッケージ</em>、言い換えると直接または間接に実際の入力機器と表示ハードウェアを操作するパッケージはコントロールファイル中に仮想パッケージ
<tt>xserver</tt>を提供することを
<footnote>
<p><!--
This implements current practice, and provides an actual
policy for usage of the "xserver" virtual package which
appears in the virtual packages list. In a nutshell, X
servers that interface directly with the display and input
hardware or via another subsystem (e.g., GGI) should provide
xserver. Things like Xvfb, Xnest, and Xprt should not.
-->
これは仮想パッケージリストにある xserver
仮想パッケージの使用法に関する現在の試行を実装し、ポリシーとしての実際の条項を提供したものです。
端的に言って、ディスプレイと入力ハードウェアに直接、または別のサブシステム経由
(GGI 等) でインターフェースする X サーバは xserver
仮想パッケージを提供すべきです。Xvfb、Xnest、Xprt
のようなものは仮想パッケージを提供すべきではありません。
</p>
</footnote> 宣言すべきです。
</p>
<p><!--
<em>Packages that provide a terminal emulator</em> for the X
Window System which support a terminal type with a terminfo
description provided in the <tt>ncurses-base</tt> package
should declare in their control data that they provide the
virtual package <tt>x-terminal-emulator</tt>. They should
also register themselves as an alternative for
<tt>/usr/bin/x-terminal-emulator</tt>, with a priority of
20.-->
<tt>ncurses-base</tt> パッケージに terminfo
情報が記載されたターミナルタイプをサポートする X
ウィンドウシステムの <em>ターミナルエミュレータを提供するパッケージ</em>はコントロールファイル中に仮想パッケージ
<tt>x-terminal-emulator</tt>を提供することを宣言すべきです。
このようなパッケージはまた自分自身をプライオリティ
20 で <tt>/usr/bin/x-terminal-emulator</tt> の代替とするよう宣言するべきです。
</p>
<p><!--
<em>Packages that provide window managers</em> should declare in
their control data that they provide the virtual package
<tt>x-window-manager</tt>. They should also register themselves as an alternative for <tt>/usr/bin/x-window-manager</tt>, with a priority
calculated as follows:-->
X ウィンドウシステムの <em>ウィンドウマネージャを提供するパッケージ</em> はコントロールファイル中に仮想パッケージ
<tt>x-window-manager</tt> を提供することを宣言すべきです。
このようなパッケージはまた自分自身を次に説明するプライオリティで
<tt>/usr/bin/x-window-manager</tt> の代替とするよう宣言するべきです。
<list>
<!-- <item>Start with a priority of 20.</item>-->
<item>まずプライオリティ 20 から始めます</item>
<item><!--If the window manager supports the Debian menu system,
add 20 points if this support is available in the
package's default configuration (i.e., no
configuration files belonging to the system or user
have to be edited to activate the feature); if
configuration files must be modified, add only 10
points.-->
ウィンドウマネージャが Debian メニューシステムをサポートしている場合、パッケージの既定設定でこのサポートが使えるようになっている
(システムやユーザの持つ設定ファイルで、この機能を有効化する必要がない)
場合、20を足してください。
設定ファイルを変更しなければならない場合、10 だけを足してください。
</item>
<item><!-- If the window manager permits the X session to be
restarted using a <em>different</em> window manager
(without killing the X server) in its default
configuration, add 10 points; otherwise add
none.-->
もしウィンドウマネージャが既定の設定下で <em>別の</em> ウィンドウマネージャを使って
X セッションを再起動可能 (X サーバを再起動せずに)
なら 10 を足してください。そうでないなら何も足しません。
</item>
</list>
</p>
<p><!--
<em>Packages that provide fonts for the X Window System</em>
must do a number of things to ensure that they are both
available without modification of the X or font server
configuration, and that they do not corrupt files used by
other font packages to register information about themselves.-->
<em>X ウィンドウシステムのフォントを提供するパッケージでは</em>
X およびフォントサーバの変更なしにそれが有効になるように、また自分自身の情報を登録する際に他のフォントパッケージの情報を壊さないよういくつかの作業を行う必要があります。
<enumlist>
<item><!--
Fonts of any type supported by the X Window System
should be be in a separate binary package from any
executables, libraries, or documentation (except that
specific to the fonts shipped); if a program or
library is <em>unusable</em> without one or more
specific fonts, the package containing the program or
library should declare a dependency on the package(s)
containing the font(s) it requires.-->
X ウィンドウシステムでサポートされるフォントはどの種類のものでもプログラムやライブラリや説明文書
(そのフォントに対するものはのぞいて)
とは別のバイナリパッケージにするべきです。
もしプログラムかライブラリが特定の一つまたは複数のフォントがなければ <em>使用できない</em>
場合には、必要とするフォントを収録したパッケージに対して依存関係を宣言するべきです。
</item>
<item><!--
BDF fonts should be converted to PCF fonts with the
<tt>bdftopcf</tt> utility (available in the
<tt>xbase-clients</tt> package, <tt>gzip</tt>ped, and
placed in a directory that corresponds to their
resolution:-->
BDF フォントは <tt>xbase-clients</tt> パッケージ収録の
<tt>bdftopcf</tt> ユーティリティを使って PCF フォントに変換し、
<tt>gzip</tt> を行い、解像度に応じたディレクトリに置くべきです。
<list>
<item><!--
100 dpi fonts should be placed in
<tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>.-->
100 dpi のフォントは
<tt>/usr/X11R6/lib/X11/fonts/100dpi/</tt>
に置くべきです。
</item>
<item><!--
75 dpi fonts should be placed in
<tt>/usr/X11R6/lib/X11/fonts/75dpi/</tt>.-->
75 dpi のフォントは
<tt>/usr/X11R6/lib/X11/fonts/75dpi/</tt>
に置くべきです。
</item>
<item><!--
Character-cell fonts, cursor fonts, and other
low-resolution fonts should be placed in
<tt>/usr/X11R6/lib/X11/fonts/misc/</tt>.-->
絵文字フォント、カーソルフォントとそのほかの低解像度のフォントは
<tt>/usr/X11R6/lib/X11/fonts/misc/</tt>
に置くべきです。
</item>
</list>
</item>
<item><!--
Speedo fonts should be placed in
<tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt>.-->
Speedo フォントは
<tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt> に置くべきです。
</item>
<item><!--
Type 1 fonts should be placed in
<tt>/usr/X11R6/lib/X11/fonts/Type1/</tt>. If font
metric files are available, they may be placed here as
well.-->
Type 1 フォントは
<tt>/usr/X11R6/lib/X11/fonts/Type1/</tt> に置くべきです。
もしメトリックファイルが提供されているならそれも同じディレクトリに置いてください。
</item>
<item><!--
Subdirectories of <tt>/usr/X11R6/lib/X11/fonts/</tt>
other than those listed above should be neither created nor
used. (The <tt>PEX</tt> and <tt>cyrillic</tt> directories are
excepted for historical reasons, but installation of files into
these directories remains discouraged.)-->
上記で並べられた以外の <tt>/usr/X11R6/lib/X11/fonts/</tt>
以下のサブディレクトリを作成したり使ったりすべきではありません。
(<tt>PEX</tt> と <tt>cyrillic</tt>
ディレクトリは歴史的経緯で例外扱いされていますが、これらディレクトリ中にファイルをインストールすることはやはり避けたほうがいいでしょう。)
</item>
<item><!--
Font packages may, instead of placing files directly in
the X font directories listed above, provide symbolic links in
the font directory which point to the files' actual location
in the filesystem. Such a location should comply with the
FHS.-->
フォントパッケージは上記の X
フォントディレクトリに直接ファイルをおかず、ファイルシステム中の実際の場所を指すシンボリックリンクをフォントディレクトリに置くようにしてもかまいません。
この場合、実際にフォントを置く場所は FHS 準拠の場所にしてください。
</item>
<item><!--
Font packages should not contain both 75dpi and 100dpi
versions of a font. If both are available, they should be
provided in separate binary packages with "-75dpi" or "-100dpi"
appended to the names of the packages containing the
corresponding fonts.-->
フォントパッケージに 75dpi と 100dpi の両バージョンのフォントを収録すべきではありません。
もし両方の解像度のものがあるなら、そのフォントを収録したパッケージ名に
"-75dpi" と
"-100dpi" を付けた独立のバイナリパッケージを提供してください。
</item>
<item><!--
Fonts destined for the <tt>misc</tt> subdirectory should
not be included in the same package as 75dpi or 100dpi fonts;
instead, they should be provided in a separate package with
"-misc" appended to its name.-->
<tt>misc</tt>サブディレクトリに収録されるフォントは、同じパッケージ中に
75dpi や 100dpi のフォントを収録していてはいけません。
その代わりに、そのフォントを収録したパッケージ名に
"-misc" を付けた独立のバイナリパッケージを提供してください。
</item>
<item><!--
Font packages <em>must not</em> provide the files
<tt>fonts.dir</tt>, <tt>fonts.alias</tt>, or
<tt>fonts.scale</tt> in a font directory.-->
フォントパッケージはフォントディレクトリ中に
<tt>fonts.dir</tt>、<tt>fonts.alias</tt> 及び
<tt>fonts.scale</tt> の各ファイルを収録しては <em>いけません</em>。
<list>
<item><!--
<tt>fonts.dir</tt> files must not be provided at
all.-->
<tt>fonts.dir</tt> ファイルはどのような形でも収録してはいけません。
</item>
<item><!--
<tt>fonts.alias</tt> and <tt>fonts.scale</tt>
files, if needed, should be provided in the
directory
<tt>/etc/X11/fonts/<em>fontdir</em>/<em>package</em>.
<em>extension</em></tt>, where <em>fontdir</em> is the
name of the subdirectory of
<tt>/usr/X11R6/lib/X11/fonts/</tt> where the
package's corresponding fonts are stored (e.g.,
<tt>75dpi</tt> or <tt>misc</tt>),
<em>package</em> is the name of the package that
provides these fonts, and <em>extension</em> is
either <tt>scale</tt> or <tt>alias</tt>,
whichever corresponds to the file
contents.-->
<tt>fonts.alias</tt> と <tt>fonts.scale</tt> ファイルは必要なら
<tt>/etc/X11/fonts/<em>fontdir</em>/
<em>package</em>.<em>extension</em></tt>
ディレクトリに収録すべきです。ここで
<em>fontdir</em> は関連フォントが収録される
<tt>/usr/X11R6/lib/X11/fonts/</tt>
以下のサブディレクトリ名
(つまり、<tt>75dpi</tt> や <tt>misc</tt> など)で、
<em>package</em> はそのフォントを収録したパッケージの名前です。
また、<em>extension</em> はファイルの内容に従い
<tt>scale</tt> か <tt>alias</tt>
のどちらかになります。
</item>
</list>
</item>
<item><!--
Font packages must declare a dependency on
<tt>xbase-clients</tt> and, in the package
post-installation and post-removal scripts, invoke the
<tt>mkfontdir</tt> command on each directory into
which they installed fonts.-->
フォントパッケージは <tt>xbase-clients</tt> への依存関係を宣言しなければいけません。
また、パッケージの post-installation と post-removal
スクリプトでフォントをインストールした各ディレクトリで
<tt>mkfontdir</tt>
を実行しなければいけません。
</item>
<item><!--
Font packages that provide one or more
<tt>fonts.scale</tt> files as described above must declare a
versioned dependency on <tt>xbase-clients (>=
3.3.3.1-5)</tt> and invoke <tt>update-fonts-scale</tt> on
each directory into which they installed fonts
<em>before</em> invoking <tt>mkfontdir</tt> on that
directory. This invocation must occur in both the
post-installation and post-removal scripts.-->
一つまたは複数の <tt>fonts.scale</tt> ファイルを収録するフォントパッケージでは、上記の通り
<tt>xbase-clients (>= 3.3.3.1-5)</tt>
にバージョンを含む依存関係を宣言しなければならず、またフォントをインストールした各ディレクトリで
<tt>mkfontdir</tt> を実行するまえに
<tt>update-fonts-scale</tt> を実行しなければいけません。
この実行処理はパッケージの post-installation と
post-removal スクリプトで行われなければいけません。
</item>
<item><!--
Font packages that provide one or more
<tt>fonts.alias</tt> files as described above must
declare a versioned dependency on <tt>xbase-clients
(>= 3.3.3.1-5)</tt> and, in the package
post-installation and post-removal scripts, invoke
<tt>update-fonts-alias</tt> on each directory into
which they installed fonts.-->
一つまたは複数の<tt>fonts.alias</tt>ファイルを収録するフォントパッケージでは、上記の通り
<tt>xbase-clients (>= 3.3.3.1-5)</tt>
にバージョンを含む依存関係を宣言しなければならず、またパッケージの
post-installation とpost-removal
スクリプトでフォントをインストールした各ディレクトリで
<tt>update-fonts-alias</tt> を実行しなければいけません。
</item>
<item><!--
Font packages must not provide alias names for the
fonts they include which collide with alias names already in
use by fonts already packaged.-->
フォントパッケージは既にパッケージ化されている他のフォントと同じエイリアス名と衝突するエイリアス名でフォントを収録してはいけません。
</item>
<item><!--
Font packages must not provide fonts with the same XLFD
registry name as another font already packaged.-->
フォントパッケージは既にパッケージ化されている他のフォントと同じ XLFD レジストリ名でフォントを収録してはいけません。
</item>
</enumlist>
</p>
<!-- ################################################ -->
<p><!--
<em>Application defaults</em> files must be installed in the
directory <tt>/etc/X11/app-defaults/</tt> (use of a
localized subdirectory of <tt>/etc/X11/</tt> as described in
the <em>X Toolkit Intrinsics - C Language Interface</em>
manual is also permitted). They must be registered as
<em>conffile</em>s or handled as configuration files. For
programs that are not linked against the X Toolkit (Xt)
library, customization of programs' X resources may also be
supported with the provision of a file with the same name as
that of the package placed in the
<tt>/etc/X11/Xresources/</tt> directory, which must
registered as a <em>conffile</em> or handled as a
configuration file. <em>Important:</em> packages that
install files into the <tt>/etc/X11/Xresources/</tt>
directory <em>must</em> declare a conflict with <tt>xbase
(<< 3.3.2.3a-2)</tt>; if this is not done it is
possible for the installing package to destroy a
previously-existing <tt>/etc/X11/Xresources</tt> file which
had been customized by the system administrator.-->
<em>アプリケーションデフォルト</em>ファイルは
<tt>/etc/X11/app-defaults/</tt>
にインストールしなければいけません(<em>X Toolkit Intrinsics -
C Language Interface</em> マニュアル記載のように <tt>/etc/X11/</tt>
下のサブディレクトリをローカルに使用することは許されます)。
これらは <em>conffile</em> であるとの属性を設定し、設定ファイルとしての扱いを行わなければいけません。
X ツールキット (Xt) とリンクしていないプログラムでも、
プログラムの X リソースの設定は、<tt>/etc/X11/Xresources/</tt>
にパッケージと同じ名前のファイルを用意することによって行うことができます。
このファイルは <em>conffile</em> として登録しなければいけません。
<em>重要</em> <tt>/etc/X11/Xresources/</tt>
ディレクトリにファイルをインストールするパッケージは
<tt>xbase (<<3.3.2.3a-2)</tt> へのコンフリクトを宣言してください。
これがなされていないと、パッケージのインストールの際に既存のシステム管理者の設定した
<tt>/etc/X11/Xresources</tt> の中の
<em>ファイル</em> を壊す可能性があります。
</p>
<p><!--
<em>Packages using the X Window System should abide by the FHS
standard whenever possible</em>; they should install binaries,
libraries, manual pages, and other files in FHS-mandated
locations wherever possible. This means that files must
not be installed into <tt>/usr/X11R6/bin/</tt>,
<tt>/usr/X11R6/lib/</tt>, or <tt>/usr/X11R6/man/</tt> unless
this is necessary for the package to operate properly.
Configuration files for window managers and display managers
should be placed in a subdirectory of <tt>/etc/X11/</tt>
corresponding to the package name due to these programs'
tight integration with the mechanisms of the X Window
System. Application-level programs should use the
<tt>/etc/</tt> directory unless otherwise mandated by
policy. The installation of files into subdirectories of
<tt>/usr/X11R6/include/X11/</tt> and
<tt>/usr/X11R6/lib/X11/</tt> is permitted but discouraged;
package maintainers should determine if subdirectories of
<tt>/usr/lib/</tt> and <tt>/usr/share/</tt> can be used
instead (symlinks from the X11R6 directories to
FHS-compliant locations is encouraged if the program is not
easily configured to look elsewhere for its files).
Packages must not provide -- or install files into --
the directories <tt>/usr/bin/X11/</tt>,
<tt>/usr/include/X11/</tt>, or <tt>/usr/lib/X11/</tt>.
Files within a package should, however, make reference to
these directories, rather than their X11R6-named
counterparts <tt>/usr/X11R6/bin/</tt>,
<tt>/usr/X11R6/include/X11/</tt>, and
<tt>/usr/X11R6/lib/X11/</tt>, if the resources being
referred to have not been moved to FHS-compliant locations.-->
<em>X ウィンドウシステムを使うパッケージは可能な際には FHS 標準に準拠するべきです</em>。
つまり、バイナリやライブラリやマニュアルページやその他のファイルを
FHS の指示する場所にインストールすべきです。
これはパッケージが正しく動作しないと言うことがない限り、ディレクトリ
<tt>/usr/bin/X11R6/</tt>、<tt>/usr/share/doc/X11R6/</tt>、
<tt>/usr/include/X11R6/</tt> や <tt>/usr/lib/X11R6/</tt>
にファイルをインストールしてはいけないことを意味します。
ディスプレイマネージャやウィンドウマネージャの設定ファイルは
<tt>/etc/X11/</tt> ディレクトリ以下のパッケージ名称のサブディレクトリにインストールしてください。
これは、これらのプログラムが X ウィンドウシステムの動作と密に関連するためです。
アプリケーションレベルのプログラムは、ポリシー中で別途指示されていない限り
<tt>/etc/</tt> 以下を用いてください。サブディレクトリ
<tt>/usr/X11R6/include/X11/</tt> と
<tt>/usr/X11R6/lib/X11/</tt> 以下にファイルをインストールすることは許されていますが、できるだけ避けてください。
パッケージメンテナは
<tt>/usr/lib/</tt> か <tt>/usr/share/</tt>
が代わりに使えないか判断するべきです
(プログラムがファイルを他の場所で探すように簡単に変更するのが難しい場合には
X11R6 ディレクトリから FHS
準拠の場所へシンボリックリンクを張る解決は推奨できます)。
ディレクトリ
<tt>/usr/bin/X11/</tt>、<tt>/usr/share/doc/X11/</tt>、
<tt>/usr/include/X11/</tt> や <tt>/usr/lib/X11/</tt>
にファイルをインストールしてはいけません。
但し、パッケージ内のファイルは、もしリソースが
FHS 準拠の場所に移されていないならば、これらの
ディレクトリ (対応する X11R6 名称の <tt>/usr/X11R6/bin/</tt>、
<tt>/usr/X11R6/include/X11/</tt> と <tt>/usr/X11R6/lib/X11/</tt>
ではなく) に対してリンクを張るべきです。
</p>
<p><!--
<em>Programs that require the non-DFSG-compliant OSF/Motif
library</em> should be compiled against and tested with
LessTif (a free re-implementation of Motif) instead. If the
maintainer judges that the program or programs do not work
sufficiently well with LessTif to be distributed and
supported, but do so when compiled against Motif, then two
versions of the package should be created; one linked
statically against Motif and with <tt>-smotif</tt> appended
to the package name, and one linked dynamically against
Motif and with <tt>-dmotif</tt> appended to the package
name. Both Motif-linked versions are dependent upon
non-DFSG-compliant software and thus cannot be uploaded to
the main distribution; if the software is itself
DFSG-compliant it may be uploaded to the contrib
distribution. While known existing versions of OSF/Motif
permit unlimited redistribution of binaries linked against
the library (whether statically or dynamically), it is the
package maintainer's responsibility to determine whether
this is permitted by the license of the copy of OSF/Motif in
his or her possession.-->
<em>DFSG に準拠しない OSF/Motif ライブラリを必要とするプログラム</em>では、Motif
の別実装でフリーな LessTif で問題なく動作するかを調べるべきです。
もし、Motif では動作するプログラムが
LessTif では配布、サポートに耐えるだけ満足に動作しないとメンテナが判断したならば、二つの版のパッケージ、一方は
Motif ライブラリに静的にリンクし "-smotif" 、もう一方は
Motif ライブラリに動的にリンクし "-dmotif"
をパッケージ名に付けたものを作成すべきです。
どちらの Motif にリンクしたパッケージも DFSG に準拠しないソフトウェアに依存しているので、main
ディストリビューションにはアップロードできません。
一方、知られている OSF/Motif の各版はすべて静的にリンクされたバイナリの再配布を許していますが、使っている Motif
のライセンスで再配布が可能かどうかを確認するのはメンテナの責任です。
</p>
</sect>
<sect>
<!--<heading>Perl programs and modules</heading>-->
<heading>Perl プログラムとモジュール群</heading>
<p><!--
Perl programs and modules should follow the current Perl
policy as defined in the file found on
<ftpsite>ftp.debian.org</ftpsite> in
<ftppath>/debian/doc/package-developer/perl-policy.txt.gz</ftppath>
or your local mirror. In addition, it is included in the
<tt>debian-policy</tt> package.-->
Perl プログラムとモジュールは、現在の Perl ポリシーに従うべきです。
この Perl ポリシーは <ftpsite>ftp.debian.org</ftpsite> の
<ftppath>/debian/doc/package-developer/perl-policy.txt.gz</ftppath>
ファイル、またはお近くのミラーから取得できます。また、これは
<tt>debian-policy</tt> パッケージにも収録されています。
</p>
</sect>
<sect>
<!-- <heading>Emacs lisp programs</heading>-->
<heading>Emacs lisp プログラム</heading>
<p>
<!-- Please refer to the `Debian Emacs Policy' (documented in
<tt>debian-emacs-policy.gz</tt> of the
<prgn>emacsen-common</prgn> package) for details of how to
package emacs lisp programs.-->
emacs lisp プログラムをパッケージングする際には『Debian Emacs
Policy』(<prgn>emacsen-common</prgn> パッケージの文書中に
<tt>debian-emacs-policy.gz</tt> という名で収録されています) に当たってください。
</p></sect>
<sect>
<!-- <heading>Games</heading>-->
<heading>ゲーム</heading>
<p>
<!-- The permissions on /var/games are 755
<tt>root.root</tt>.-->
/var/games のパーミッションは 755 <tt>root.root</tt> です。
</p>
<p>
<!-- Each game decides on its own security policy.-->
各ゲームは個々にセキュリティ方針を決めてかまいません。</p>
<p>
<!-- Games which require protected, privileged access to
high-score files, savegames, etc., may be made
set-<em>group</em>-id (mode 2755) and owned by
<tt>root.games</tt>, and use files and directories with
appropriate permissions (770 <tt>root.games</tt>, for
example). They must not be made
set-<em>user</em>-id, as this causes security problems. (If
an attacker can subvert any set-user-id game they can
overwrite the executable of any other, causing other players
of these games to run a Trojan horse program. With a
set-group-id game the attacker only gets access to less
important game data, and if they can get at the other
players' accounts at all it will take considerably more
effort.)-->
ハイスコアファイル、保存ファイルなどの保護され、アクセスに特権
が必要なファイルを持つゲームは、オーナ・グループを
<tt>root.games</tt> にして 2755 で set-gid しておき、ファイルとディレクトリには適当なパーミッション
(例えば、770 <tt>root.games</tt>) を与えてもかまいません。
set-uid はセキュリティ上の問題が起きるのでしてはいけません
(アタックする人は set-uid
されたゲームを破ることができたら、そのファイルを他の実行ファイルで上書きし、ほかのプレイヤーがトロイの木馬を実行してしまうことになります。
set-gid されたゲームでは、アタッカーはあまり重要ではないゲームのデータだけにアクセスできるようになるだけで、
ほかのプレイヤーのアカウントを手にいれることができるとしても、そこから更にかなりの労力を費すことになるでしょう)。
</p>
<p>
<!-- Some packages, for example some fortune cookie programs, are
configured by the upstream authors to install with their
data files or other static information made unreadable so
that they can only be accessed through set-id programs
provided. You should not do this in a Debian package: anyone can
download the <tt>.deb</tt> file and read the data from it,
so there is no point making the files unreadable. Not
making the files unreadable also means that you don't have
to make so many programs set-id, which reduces the risk of a
security hole.-->
一部のパッケージ、例えば fortune cookie プログラムでは、データファイルやその他の静的な情報を読み込み不可でインストールし、提供される
set-id されたプログラムによってのみアクセスできるように、上流の開発者が設定しています。
このようなことを Debian パッケージでやるべきではありません。
なんとなれば誰でも <tt>.deb</tt>
ファイルをダウンロードしてきて中身を読むことができますから、読み込み不可のファイルを使っても無意味なためです。
また、読み込み不可のファイルを作らないことは
set-id されたプログラムをたくさん作る必要がなくなることを意味しますし、引いてはセキュリティホールのリスクを減らすことにもなります。
</p>
<p>
<!-- As described in the FHS, binaries of games should be
installed in the directory <tt>/usr/games</tt>. This also
applies to games that use the X Window System. Manual pages
for games (X and non-X games) should be installed in
<tt>/usr/share/man/man6</tt>.-->
FHS で規定されているように、ゲームのバイナリは
<tt>/usr/games</tt> にインストールしてください。X ウィンドウシステムを使うゲームもここに入れてください。ゲームのマニュアル
(X 用、X 不使用の両方とも) は
<tt>/usr/share/man/man6</tt> にインストールしてください。</p>
</sect>
</chapt>
<!-- <chapt><heading>Documentation</heading> -->
<chapt><heading>文書</heading>
<sect>
<!-- <heading>Manual pages</heading> -->
<heading>マニュアル(man ページ)</heading>
<p><!--
You should install manual pages in <prgn>nroff</prgn> source
form, in appropriate places under <tt>/usr/share/man</tt>. You
should only use sections 1 to 9 (see the FHS for more
details). You must not install a preformatted `cat
page'.-->
マニュアルは <prgn>nroff</prgn> 形式で <tt>/usr/share/man</tt>
の適切な場所にインストールするべきです。また、セクションは
1 から 9 までのみをつかうべきです (詳しくは FHS 参照)。
フォーマット済みの 'cat' 形式のマニュアルをインストールしてはいけません。
</p>
<p><!--
Each program, utiltiy, and function should have an
associated manpage included in the same package. It is
suggested that all configuration files also have a manual
page included as well.-->
各プログラム、ユーティリティ、機能はそれに関連するマニュアルページを同じパッケージに含めるべきです。
すべての設定ファイルもそれに関連するマニュアルページを含めることを推奨します。
</p>
<p>
<!-- If no manual page is available for a particular program,
utility, function or configuration file and this is reported as a bug debian-bugs, a symbolic link from the requested manual page
to the <manref name="undocumented" section="7"> manual page
may be provided. This symbolic link can be created from
<tt>debian/rules</tt> like this:
<example>
ln -s ../man7/undocumented.7.gz \
debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz
</example>
This manpage claims that the lack of a manpage has been
reported as a bug, so you may only do this if it really has
(you can report it yourself, if you like). Do not close the
bug report until a proper manpage is available. -->
特定のプログラム、ユーティリティ、関数や設定ファイルでマニュアルが存在せず、そのことが
debian-bugs で bug として報告済みになっている場合、
対応するマニュアルページを <manref name="undocumented" section="7">
マニュアルへのシンボリックリンクにしておいてもかまいません。
このシンボリックリンクは次のようにして <tt>debian/rules</tt>
で作成することができます。
<example>
ln -s ../man7/undocumented.7.gz \
debian/tmp/usr/share/man/man[1-9]/the_requested_manpage.[1-9].gz
</example>
このマニュアルページにはマニュアルの欠如はバグとして既に報告されていると明記されています。
言い換えれば上記のように処理していいのは本当にバグとしての報告が既になされている場合のみです
(自分で報告しておく、という処理でもかまいません)。
適切なマニュアルが収録されるまではバグ報告を閉じないでください。
</p>
<p>
<!-- You may forward a complaint about a missing manpage to the
upstream authors, and mark the bug as forwarded in the
Debian bug tracking system. Even though the GNU Project do
not in general consider the lack of a manpage to be a bug,
we do--if they tell you that they don't consider it a bug
you should leave the bug in our bug tracking system open
anyway. -->
上流の作者にマニュアルがないとの苦情を転送し、Debian バグトラッキングシステムでは
『転送済み』という処理にしてもかまいません。
GNU プロジェクトではマニュアルがないことは通常バグではないとしていますが、私たちはバグと見なします。
彼らがバグではないと連絡してきた場合では、何も処理せずに Debian
バグトラッキングシステム上では『未解決』のままにしておいてください。
</p>
<p>
<!-- Manual pages should be installed compressed using <tt>gzip
-9</tt>.-->
マニュアルは <tt>gzip -9</tt> で圧縮してインストールしなければいけません。
</p>
<p>
<!-- If one manpage needs to be accessible via several names it
is better to use a symbolic link than the <tt>.so</tt>
feature, but there is no need to fiddle with the relevant
parts of the upstream source to change from <tt>.so</tt> to
symlinks--don't do it unless it's easy. You should not
create hard links in the manual page directories, nor put
absolute filenames in <tt>.so</tt> directives. The filename
in a <tt>.so</tt> in a manpage should be relative to the
base of the manpage tree (usually
<tt>/usr/share/man</tt>). -->
一つのマニュアルページを複数の名前で参照する必要がある場合は、
<tt>.so</tt> 機能を使うよりもシンボリックリンクを使う方が望ましいやり方です。
ただ、上流のソースが <tt>.so</tt> を使っている場合、それをあえてシンボリックリンクへ変更する必要はありません。
それが余程簡単でないかぎり行わないでください。
マニュアルのディレクトリではハードリンクを作成すべきではありません。
また、<tt>.so</tt> 命令の中に絶対パスのファイル名を書くべきではありません。
マニュアルの
<tt>.so</tt> 命令ではファイルはマニュアルツリーの起点 (通常は
<tt>/usr/share/man</tt> です) からの相対参照とすべきです。
</p>
</sect>
<sect>
<!-- <heading>Info documents</heading> -->
<heading>Info 形式の文書</heading>
<p>
<!-- Info documents should be installed in <tt>/usr/share/info</tt>.
They should be compressed with <tt>gzip -9</tt>. -->
info 形式の文書は <tt>/usr/share/info</tt> へインストールしてください。
また <tt>gzip -9</tt> で圧縮しておいてください。
</p>
<p>
<!-- Your package should call <prgn>install-info</prgn> to update
the Info <tt>dir</tt>
file, in its post-installation script:-->
パッケージは Info システムの <tt>dir</tt> ファイルを更新するために
postinst スクリプト中で <prgn>install-info</prgn> を呼び出すべきです。
<example>
install-info --quiet --section Development Development \
/usr/share/info/foobar.info
</example>
</p>
<p>
<!-- It is a good idea to specify a section for the location of
your program; this is done with the <tt>--section</tt>
switch. To determine which section to use, you should look
at <tt>/usr/share/info/dir</tt> on your system and choose the most
relevant (or create a new section if none of the current
sections are relevant). Note that the <tt>--section</tt>
flag takes two arguments; the first is a regular expression
to match (case-insensitively) against an existing section,
the second is used when creating a new one.-->
あなたのプログラムの場所を示すためにセクションを指定するのは良いことです。
それには <tt>--section</tt> オプションを使用してください。
どのセクションにするかは、自分のシステムの
<tt>/usr/share/info/dir</tt> を見て最もふさわしいものを選んでください。
適当なものが見付からない場合は新しいセクションを作成してください。
<tt>--section</tt>オプションは二つの引数を取ることに注意してください。
最初の引数は存在しているセクションと一致させる正規表現
(大文字小文字は区別しません) で、もう一つは最初の引数に一致するセクションがないときに作成する、新しいセクション名として使います。
</p>
<p>
<!-- You should remove the entries in the pre-removal script:-->
prerm スクリプト中では、次のようにしてエントリを削除するべきです。
<example>
install-info --quiet --remove /usr/share/info/foobar.info
</example>
</p>
<p>
<!-- If <prgn>install-info</prgn> cannot find a description entry
in the Info file you must supply one. See <manref
name="install-info" section="8"> for details.-->
<prgn>install-info</prgn> が info ファイル中に説明部のエントリ
ポイントを見つけられない場合、エントリポイントを付け足さなければなりません。
この件の詳細は <manref name="install-info" section="8">
を参考にしてください。
</p>
</sect>
<sect>
<!-- <heading>Additional documentation</heading> -->
<heading>追加文書</heading>
<p>
<!-- Any additional documentation that comes with the package may
be installed at the discretion of the package maintainer.
Text documentation should be installed in a directory
<tt>/usr/share/doc/<var>package</var></tt>, where
<var>package</var> is the name of the package, and
compressed with <tt>gzip -9</tt> unless it is small.-->
パッケージに付属しているそれ以外の文書はパッケージメンテナの裁量でインストールするかどうかを決めて下さい。
テキスト形式の文書は
<tt>/usr/share/doc/<var>package</var></tt> (<var>package</var>
はパッケージの名称です) にインストールし、小さなものでない限り
<tt>gzip -9</tt> で圧縮しておいてください。
</p>
<p>
<!-- If a package comes with large amounts of documentation which
many users of the package will not require you should create
a separate binary package to contain it, so that it does not
take up disk space on the machines of users who do not need
or want it installed. -->
対象とするパッケージを使うほとんどのユーザが必要としないような多量の文書を含むようなパッケージは、
そのような文書を収録した独立のパッケージを作成して、そのような文書を必要としないか、インストールしたくないユーザがマシンのディスクスペースを消費しなくてもいいようにしておくべきです。
</p>
<p>
<!-- It is often a good idea to put text information files
(<tt>README</tt>s, changelogs, and so forth) that come with
the source package in <tt>/usr/share/doc/<var>package</var></tt>
in the binary package. However, you don't need to install
the instructions for building and installing the package, of
course!-->
バイナリパッケージ中の <tt>/usr/share/doc/<var>package</var></tt>
にソースパッケージに付いている各種のテキスト文書 (<tt>README</tt>
や changelog など) を入れるのは通常よい考えです。
ただ、まぁ当り前のことですが、パッケージの作成やインストール方法について書かれたものを含める必要はありません。
</p>
<p><!--
Files in <tt>/usr/share/doc</tt> should not be referenced by
any program, and the system administrator should be able to
delete them without causing any programs to break. Any files
that are referenced by programs but are also useful as
standalone documentation should be installed under
<tt>/usr/share/<package>/</tt> and symlinked in
<tt>/usr/share/doc/<package>/</tt>. -->
システム管理者が <tt>/usr/share/doc</tt>
中のファイルを消してもプログラムが動かなくなることがないよう、
このディレクトリ以下のファイルをプログラムから参照するようにしてはいけません。
プログラムから参照されるが、同時に単独のドキュメントとしても役に立つようなファイルは <tt>/usr/share/<package>/</tt>
以下にインストールして、<tt>/usr/share/doc/<package>/</tt>
へシンボリックリンクを張ってください。
</p>
</sect>
<sect id="usrdoc">
<!-- <heading>Accessing the documentation</heading> -->
<heading>文書の管理</heading>
<p>
<!-- Former Debian releases placed all additional documentation
in <tt>/usr/doc/<var>package</var></tt>. To realize a
smooth migration to
<tt>/usr/share/doc/<var>package</var></tt>, each package
must maintain a symlink <tt>/usr/doc/<var>package</var></tt>
that points to the new location of its documentation in
<tt>/usr/share/doc/<var>package</var></tt><footnote>These
symlinks will be removed in the future, but they have to be
there for compatibility reasons until all packages have
moved and the policy is changed accordingly.</footnote>.
The symlink must be created when the package is installed;
it cannot be contained in the package itself due to problems
with <prgn>dpkg</prgn>. One reasonable way to accomplish
this is to put the following in the package's
<prgn>postinst</prgn>:-->
以前の Debian リリースでは添付文書類は
<tt>/usr/doc/<var>package</var></tt>
ディレクトリに収録されていました。
現在使われている <tt>/usr/share/doc/<var>package</var></tt>
ディレクトリへのスムーズな移行のために、各パッケージは
<tt>/usr/doc/<var>package</var></tt> から新しい文書の位置
<tt>/usr/share/doc/<var>package</var></tt> へのシンボリックリンクを
<footnote>
このシンボリックリンクはいずれは削除されるでしょうが、全パッケージの移行が完了してポリシーの変更がなされるまでは互換性のために置かなければいけません。
</footnote>
管理しなければいけません。このシンボリックリンクはパッケージをインストールしたときに作成しなければなりませんが、
<prgn>dpkg</prgn> の問題のために単にパッケージにそのリンクを含めておくことはできません。
妥当な方法は、パッケージの
<prgn>postinst</prgn> スクリプトに次の処理を含めておくことです。
<example>
if [ "$1" = "configure" ]; then
if [ -d /usr/doc -a ! -e /usr/doc/#PACKAGE# \
-a -d /usr/share/doc/#PACKAGE# ]; then
ln -sf ../share/doc/#PACKAGE# /usr/doc/#PACKAGE#
fi
fi
</example>
<!-- And the following in the package's <prgn>prerm</prgn>: -->
そして次の処理をパッケージの <prgn>prerm</prgn> に入れてください。
<example>
if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
-a -L /usr/doc/#PACKAGE# ]; then
rm -f /usr/doc/#PACKAGE#
fi
</example>
</p>
</sect>
<sect>
<!-- <heading>Preferred documentation formats</heading>-->
<heading>好ましい文書形式</heading>
<p>
<!-- The unification of Debian documentation is being carried out
via HTML.-->
Debian プロジェクトでは 文書の形式の統一化は HTML を通して行なわれています。
</p>
<p>
<!-- If your package comes with extensive documentation in a
mark up format that can be converted to various other formats
you should if possible ship HTML versions in a binary
package, in the directory
<tt>/usr/share/doc/<var>appropriate package</var></tt> or its
subdirectories.-->
パッケージに各種書式に変換可能なマークアップ形式の詳細文書が付属している場合は、バイナリパッケージには可能なかぎり HTML 形式のものを
<footnote>
<p><!-- The rationale: The important thing here is that HTML
docs should be available in <em>some</em> package, not
necessarily in the main binary package, though. -->
原則の解説：ここで重要なことは、HTML 形式の文書は <em>一部</em> のパッケージには収録されていますが、現時点ではまだ
main のバイナリパッケージ全部に収録されているわけではないということです。
</p>
</footnote> <tt>/usr/share/doc/<var>package</var></tt>、
およびそのサブディレクトリにインストールしてください。
</p>
<p>
<!-- Other formats such as PostScript may be provided at your
option.-->
PostScript のような他の形式は自分の好みで提供してください。</p>
</sect>
<sect id="copyrightfile">
<!-- <heading>Copyright information</heading> -->
<heading>著作権関連情報</heading>
<p>
<!-- Every package must be accompanied by a verbatim copy of its
copyright and distribution license in the file
/usr/share/doc/<package-name>/copyright. This file must
neither be compressed nor be a symbolic link.-->
各パッケージには、著作権と配布条件のライセンス文書が元のままの形式で
/usr/share/doc/<package-name>/copyright に収録されていなければいけません。
このファイルは圧縮されていたり、シンボリックリンクであったりしてはいけません
<footnote>
訳注：本節後半の GPL ほかの項参照
</footnote>。
</p>
<p>
<!-- In addition, the copyright file must say where the upstream
sources (if any) were obtained, and should explain briefly what
modifications were made in the Debian version of the package
compared to the upstream one. It should name the original
authors of the package and the Debian maintainer(s) who were
involved with its creation. -->
また、著作権情報ファイル中には元となった上流のソースをどこから手に入れたかを記載しなければなりません。
また、元のソースから Debian パッケージを作成するためにどのような変更を行なったかを簡潔に書いておくべきです。
またパッケージの原作者の名前とパッケージ作成に関与した
Debian メンテナの名前を載せるべきです。
</p>
<p>
<!-- A copy of the file which will be installed in
<tt>/usr/share/doc/<var>package</var>/copyright</tt> should be
in <tt>debian/copyright</tt>.-->
<tt>debian/copyright</tt>と同じファイルが
<tt>/usr/share/doc/<var>package</var>/copyright</tt>
にインストールされるファイルのコピーは <tt>debian/copyright</tt>
に収録しておくべきです。
</p>
<p>
<!-- /usr/share/doc/<package-name> may be a symbolic link to a
directory in /usr/share/doc only if two packages both come from
the same source and the first package has a "Depends"
relationship on the second. These rules are important
because copyrights must be extractable by mechanical
means.-->
/usr/share/doc/<package-name> は、シンボリックリンクの相手先と同じソースファイルから作成されたものであること、および相手先に対して
"Depends" で依存していることが宣言されていること、の二つの条件を満たすときのみ、シンボリックリンクとすることができます。
この規則は著作権関連ファイルが機械的に抽出できるようにするために大切になるものです。
</p>
<p>
<!-- Packages distributed under the UCB BSD license, the Artistic
license, the GNU GPL, and the GNU LGPL should refer to the
files /usr/share/common-licenses/BSD,
/usr/share/common-licenses/Artistic,
/usr/share/common-licenses/GPL, and
/usr/share/common-licenses/LGPL.-->
パッケージがカリフォルニア大学バークレイ校の BSD ライセンス、
Artistic Licence、GNU の GPL、GNU の LGPL に基づいて配布されている場合には、おのおの
/usr/share/common-licenses/BSD、
/usr/share/common-licenses/Artistic、
/usr/share/common-licenses/GPL、
/usr/share/common-licenses/LGPL の各ファイルを参照するように
<footnote>
<p>
<!-- Why "licenses" and not "copyright"? Because
<tt>/usr/doc/copyright</tt> used to contain all the
copyright files, plus the four common licenses GPL,
LGPL, Artistic and BSD. Now individual copyright files
for packages are no longer in a common directory. Once
<tt>/usr/doc/copyright</tt> is almost empty it makes
sense to rename "copyright" to "licenses"-->
ディレクトリ名が『ライセンス (license)』であって『著作権
(copyright)』ではない理由を簡単に説明します。以前は
<tt>/usr/doc/copyright</tt> に全パッケージの著作権情報
と上記 4 つ (GPL、LGPL、Artistic と BSD)
の汎用ライセンスが収録されていました。
これが、現在は個別の著作権情報は共用のディレクトリには置かなくなった、という経緯のためです。
この移行の結果、<tt>/usr/doc/copyright</tt>
はとりあえずほとんど空に近い状態になり、ライセンスのみが置かれていますので、"copyright"
から "licenses" に名称を変更しました。
</p>
<p>
<!-- Why "common-licenses" and not "licenses"? Because if I
put just "licenses" I'm sure I will receive a bug report
saying "license foo is not included in the licenses
directory". They are not all the licenses, just a few
common ones. I could use /usr/share/doc/common-licenses
but I think this is too long, and, after all, the GPL
does not "document" anything, it is merely a license.
-->
ディレクトリ名称が 『共用ライセンス (common-licenses)』
であって単に 『ライセンス (licenses)』ではないのは、単に
"licenses" としておいた場合には「ほげふがライセンスがライセンスディレクトリに収録されていない」というバグレポートを受け取る羽目になることがほとんど確実だからです。
ここに置かれるのはライセンス全部、という訳ではなく少数のよく使われているもののみです。
/usr/share/doc/common-licenses でもいいのですが、ちょっと長すぎるのと、GPL は結局のところ『ライセンス』であって文書ではないからです。
<!-- ちょっと意訳 -->
</p>
</footnote> してください。
</p>
<p><!--
You should not use the copyright file as a general <tt>README</tt>
file. If your package has such a file it should be
installed in <tt>/usr/share/doc/<var>package</var>/README</tt> or
<tt>README.Debian</tt> or some other appropriate place.-->
copyright ファイルを一般的な <tt>README</tt> として使うべきではありません。
パッケージがそのような <tt>README</tt> ファイルとして書くべき内容を持っている場合は
<tt>/usr/share/doc/<var>package</var>/README</tt>、
あるいは <tt>README.Debian</tt> やその他の適切な場所にインストールされるべきです。
</p>
</sect>
<sect>
<!-- <heading>Examples</heading> -->
<heading>設定例など</heading>
<p>
<!-- Any examples (configurations, source files, whatever),
should be installed in a directory
<tt>/usr/share/doc/<var>package</var>/examples</tt>. These
files should not be referenced by any program--they're there
for the benefit of the system administrator and users, as
documentation only. Architecture-specific example files
should be installed in a directory
<tt>/usr/lib/<var>package</var>/examples</tt>, and files in
<tt>/usr/share/doc/<var>package</var>/examples</tt> symlink
to files in it. Or the latter directory may be a symlink to
the former. -->
設定ファイルやソースファイルなどの例は
<tt>/usr/share/doc/<var>package</var>/examples</tt>
ディレクトリにインストールしてください。
これらのファイルをプログラムから参照してはいけません。
これらはシステム管理者やユーザの便宜のため、説明用として置かれている文書です。
アーキテクチャ固有の設定ファイル類は
<tt>/usr/lib/<var>package</var>/examples</tt>
にインストールし、<tt>/usr/share/doc/<var>package</var>/examples</tt>
から各ファイルにシンボリックリンクを張ってください。または、
<tt>/usr/share/doc/<var>package</var>/examples</tt> が
<tt>/usr/lib/<var>package</var>/examples</tt>
ディレクトリへのシンボリックリンクであってもかまいません。
</p>
</sect>
<sect id="instchangelog">
<!-- <heading>Changelog files</heading> -->
<heading>Changelog ファイル</heading>
<p><!--
Packages that are not Debian-native must contain a copy of
<tt>debian/changelog</tt> file from the Debian source tree
in <tt>/usr/share/doc/<var>package</var></tt> as
<tt>changelog.Debian.gz</tt>. If an upstream changelog is
available, it should be accessible as
<tt>/usr/share/doc/<var>package</var>/changelog.gz</tt> in
plain text. If the upstream changelog is distributed in
HTML, it should be made available in that form as
<tt>/usr/share/doc/<var>package</var>/changelog.html.gz</tt>
and the <tt>changelog.gz</tt> should be generated using, eg,
<tt>lynx -dump -nolist</tt>. If the upstream changelog files
do not already conform to this naming convention, then this
may be achieved either by renaming the files, or adding a
symbolic link, at the maintainer's discretion.-->
Debian 由来のものでないパッケージには、Debian ソースツリー内の
<tt>debian/changelog</tt> のコピーが
<tt>/usr/share/doc/<var>package</var></tt> 中に
<tt>changelog.Debian.gz</tt> として含まれていなければいけません。
もし上流の changelog ファイルがあれば、それは
<tt>/usr/share/doc/<var>package</var>/changelog.gz</tt>
としてプレーンテキスト形式で参照できるようにすべきです。上流の
changelog ファイルが HTML 形式で配布されているならば
<tt>/usr/share/doc/<var>package</var>/changelog.html.gz</tt>
という名称で参照できるようにすべきで
<footnote>
<p><!--
Rationale: People should not have to look into two
places for upstream changelogs merely because they are
in HTML format.-->
原則の解説: 元が HTML 形式だからといって、上流の changelog
を参照するのに二カ所を見なければならないようにすべきではありません。
</p>
</footnote>
、<tt>changelog.gz</tt> は
<tt>lynx -dump -nolist</tt> で作成すべきです。上流の changelog
ファイルがここで書いている命名規則に沿っていない場合での、ファイル名を変更する、あるいはシンボリックリンクを使うなどの処置はパッケージ開発者の裁量に任せます。
</p>
<p><!--
All these files should be installed compressed using <tt>gzip -9</tt>, as they will become large with time even if they start out small.-->
これらすべてのファイルは、はじめは小さくとも時間と共に大きくなるため、
<tt>gzip -9</tt> を使って圧縮してインストールすべきです。
</p>
<p>
<!-- If the package has only one changelog which is used both as
the Debian changelog and the upstream one because there is
no separate upstream maintainer then that changelog should
usually be installed as
<tt>/usr/share/doc/<var>package</var>/changelog.gz</tt>; if
there is a separate upstream maintainer, but no upstream
changelog, then the Debian changelog should still be called
<tt>changelog.Debian.gz</tt>.-->
上流の開発者と Debian メンテナが同一人物であるため Debian
changelog と元々の changelog が一つの changelog となっている場合は、
changelog は
<tt>/usr/share/doc/<var>package</var>/changelog.gz</tt>;
にインストールしてください。上流に別の原作者がいるけれども元々の
changelog がない場合にも、Debian の changelog は
<tt>changelog.Debian.gz</tt> のままにしてください。<P>
</p>
</sect>
</chapt>
</book>
------>8------------>8------------>8------------>8------------>8
--
Seiji Kaneko skaneko@xxxxxxxxxxxx
---------------------------------------------------------