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


かねこです。 の追従にかなりかかりそうなので (diff とったら 9000 行オ
ーバ)、平行作業ということで の現状の査読をお願いします。


#Perl policy も出来てないんだよなぁ。

<!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;

  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 メーリングリストがこの文書の内容について

  日本語訳は八田真行 mhatta@debian.or.jp 、かねこ skaneko@xxxxxxxxxxxx、
  森本 odin@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx が行い、査読を debian-doc
  メンバ debian-doc@debian.or.jp で行った。ライセンスは原文と
  同一とする。日本語訳に特有の部分には文字列 JAPANESE を含むコメントを付した。 で追加された Packaging manual 由来の部分は、早瀬 茂規 <shayase@xxxxxxxxxxxxxxx>、芳尾 桂 <shishamo@xxxxxxxxxxxxxxx> 両名による。

    <title>Debian Policy Manual</title>
      <title>Debian ポリシーマニュアル</title>
	<name>Ian Jackson </name>
	<name>Christian Schwarz</name>
      <name>revised: David A. Morris</name>
	<name>改訂: David A. Morris</name>
      <name>The Debian Policy mailing List</name>
	<name>Debian ポリシーメーリングリスト</name>
	<name>翻訳 Debian-doc-jp メーリングリスト (八田、森本、かねこ、早瀬、芳尾)</name>
    <version>version &version;, &date;</version>
      <version>バージョン &version;, &date;</version>

	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 用の policy パッケージは、ポリシー自体を編纂する権限は無い数人のメンテナによって管理されています。
	    <p>Julian Gilbey <email>jdg@debian.org</email></p>
	    <p>Manoj Srivastava <email>srivasta@debian.org</email></p>

	  Copyright &copy;1996,1997,1998 Ian Jackson
	  and Christian Schwarz.
	  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 以降のものであればどれを採用してもかまいません。

	  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
	  詳しくは GNU 一般公有使用許諾書をご覧下さい。

	  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.

    <toc detail="sect">

    <chapt id="scope">
    <heading>About this manual</heading>
	  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
	  このマニュアルでは、Debian GNU/Linux
	  Debian に要求されるいくつかの必要条件について説明します。
	  このポリシーには、Debian アーカイブの構成と内容、オペレーティングシステムとしての
	  Debian の設計に関するいくつかの事項に加えて、それぞれのパッケージがディストリビューションに受け入れられるために満たさなければならない技術的な必要条件も含まれます。
	  <!--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
	      <!-- Informally, the criteria used for inclusion is that the
	      material meet one of the following requirements:-->
		<tag><!-- Standard interfaces -->標準インターフェース</tag>
		    <!-- 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 ファイル形式がその一例です)。
		<tag><!-- Chosen Convention-->選ばれた取り決め</tag>
		    <!-- 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.-->
	      <!-- Please note that these are not mutually exclusive;
	      selected conventions often become parts of standard
	      interfaces. -->

	  <!-- The footnotes present in this manual are
	  merely informative, and are not part of Debian policy itself.-->

	<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>
	  Debian ディストリビューションに受け入れて配布することはできないと判断されます。
	  一方、<em>すべきである</em> または <em>推奨された</em> ガイドライン
	  して配布不適合とまではされません。<em>してもよい</em> または
	  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>この分類は大雑把に言って、バグ分類の <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> の類)に相当しています
		RFC 2119 参照。

	  This document assumes familiarity with these other two
	  manuals.  Unfortunately, the <em>System Administrators'
	  Manual</em> does not exist yet.
	  <em>システム管理者マニュアル</em> はまだ存在していません。
	  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
      <heading>New versions of this document</heading>
	  The current version of this document is always accessible
	  from the Debian FTP server <ftpsite>ftp.debian.org</ftpsite>
	  (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> 上の
	  具体的には、<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">
	  In addition, this manual is distributed via the Debian package
	  加えて、このマニュアルは Debian パッケージ <tt>debian-policy</tt>
	  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> ファイルも含まれています。


	  As the Debian GNU/Linux system is continuously evolving this
	  manual does so too.
	  Debian GNU/Linux システムは継続的に進化していますので、
	  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.
	  まで電子メールをお送り頂くか、<tt>debian-policy</tt> パッケージに対してバグ報告を出して頂けると幸いです。
	  この日本語訳に関するご意見ご感想は debian-doc メーリングリスト
	  <email>debian-doc@debian.or.jp</email> までお送り下さい。
	  <!-- debian-doc-jp パッケージを作成して、それに対する BTS をおこなえるようにすべき -->
    <heading>The Debian Archive</heading>
      <heading>Debian アーカイブ</heading>
	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>
	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
	Debian プロジェクトはフリーなオペレーティングシステムの構築を目指して努力を重ねていますが、私たちが利用可能にしたいと思う全てのパッケージが私たちの定義に沿った
	 <em>フリー</em> (詳しくは下記記載の <ref id="DFSG"> をご覧下さい)
	アーカイブは更に <em>main</em>、<em>non-free</em>、
	と <em>non-US/contrib</em> の各セクションに分割されています。
	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> の二つのセクションをあわせたものです。
	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 ポリシーマニュアルの記述はこれらのパッケージにも適用されます。


      <sect id="pkgcopyright">
      <heading>Package copyright and sections</heading>
	  The aims of this section are:

	  <list compact="compact">
	        to allow us to make as much software available as we
		to allow us to encourage everyone to write free software, and
	        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 を、いかなるライセンス、
	<sect1 id="DFSG">
	<heading>The Debian Free Software Guidelines</heading>
	  <heading>Debian フリーソフトウェアガイドライン</heading>
	    The Debian Free Software Guidelines (DFSG) form our
	    definition of `free' software.
	    Debian フリーソフトウェアガイドライン (DFSG) は私たちが
	    <tag>Free Redistribution</tag>
		  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 を構成する個々の部分要素 (パッケージなど)
	    <tag>Source Code</tag>
		  The program must include source code, and must allow
		  distribution in source code as well as compiled form.
	    <tag>Derived Works</tag>
		  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.
	    <tag>Integrity of The Author's Source Code</tag>
		  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.)
	    <tag>No Discrimination Against Persons or Groups</tag>
		  The license must not discriminate against any person
		  or group of persons.
	    <tag>No Discrimination Against Fields of Endeavor</tag>
		  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
	    <tag>Distribution of License</tag>
		  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
            <tag>License Must Not Be Specific to Debian</tag>
	      <tag>ライセンスは Debian においてのみ適用されるものであってはならない
		  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
            <tag>License Must Not Contaminate Other Software</tag>
		  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.
	    <tag>Example Licenses</tag>
		  The ``GPL,'' ``BSD,'' and ``Artistic'' licenses are
		  examples of licenses that we consider <em>free</em>.
		  私たちが <em>フリー</em> であると見なすライセンスの例です。
	<heading>The main section</heading>
	  <heading>main セクション</heading>
	    Every package in <em>main</em> and <em>non-US/main</em>
	    must comply with the DFSG (Debian Free Software
	    <em>main</em> および <em>non-US/main</em>
	    に収録されるパッケージは全て DFSG (Debian
	    フリーソフトウェアガイドライン) に準拠していなければなりません。

	    In addition, the packages in <em>main</em>
	    加えて、<em>main</em> に収録されるパッケージは
	    <list compact="compact">
		  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>
		  must not be so buggy that we refuse to support them,
		  must meet all policy requirements presented in this
	    <!-- Similarly, the packages in <em>non-US/main</em>-->
	    同様に、<em>non-US/main</em> に収録されるパッケージは
	    <list compact="compact">
		   <!-- must not require a package outside of <em>main</em> or
		   <em>non-US/main</em> for compilation or execution,-->
		   コンパイルおよび実行に <em>main</em> または
		  must not be so buggy that we refuse to support them,
		  must meet all policy requirements presented in this
	<heading>The contrib section</heading>
	  <heading>contrib セクション</heading>
	    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 に準拠していなければなりません。
	    In addition, the packages in <em>contrib</em> and
	    これに加えて、<em>contrib</em> と <em>non-US/contrib</em>
	    <list compact="compact">
		  must not be so buggy that we refuse to support them,
		  and -->
		  must meet all policy requirements presented in this

	    Furthermore, packages in <em>contrib</em> must not require
	    a package in a <em>non-US</em> section for compilation or
	    更に、<em>contrib</em> のパッケージはコンパイルおよび実行に
	    <em>non-US</em> セクションのパッケージを必要としてはなりません。

	    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">
		  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,
		  <em>contrib</em> または<em>non-free</em> に属するパッケージ、
		  wrapper packages or other sorts of free accessories for
		  non-free programs.
	  <heading>The non-free section</heading>
	  <heading>non-free セクション</heading>
	    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>
	    In addition, the packages in <em>non-free</em> and
	    これに加えて、<em>non-free</em> と <em>non-US/non-free</em>
	    <list compact="compact">
		  must not be so buggy that we refuse to support them,
		  must meet all policy requirements presented in this
		  manual that it is possible for them to meet.-->
		      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.-->
	  <heading><!--The non-US sections-->non-US セクション</heading>
	    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/main</em>、<em>non-US/contrib</em> または
	    <em>non-US/non-free</em> から適切に選ばれた
	     non-US セクションから配布しなければいけません。</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
	    <em>non-US</em> サーバではなく、通常のサーバから配布すべきです。
	<heading>Further copyright considerations</heading>
	    Every package must be accompanied by a verbatim copy of
	    its copyright and distribution license in the file
	    (see <ref id="copyrightfile"> for further details).
	    (詳細は <ref id="copyrightfile"> を参照ください)。
	    We reserve the right to restrict files from being included
	    anywhere in our archives if
	    <list compact="compact">
		  their use or distribution would break a law,
		  there is an ethical conflict in their distribution or
		  we would have to sign a license for them, or
		  their distribution would conflict with other project

	    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> に分類しなければいけません。

	    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 サイトにもそのミラーにも置いてはいけません。

	    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> のであり、そのようなプログラムに何らかの形で
	    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> で助言を求めるべきでしょう。

	    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 スタイルの著作権は問題ありません。

	    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>サブセクション</em> に分類されます。

	    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">
		  <em>subsection</em> if the package is in the
		  <em>main</em> section,-->
		  <em>subsection</em> これはパッケージが <em>main</em>
		  <em>section/subsection</em> if the package is in
		  the <em>contrib</em> or <em>non-free</em> section,
		  <em>section/subsection</em> これはパッケージが
		  <em>contrib</em> または <em>non-free</em>
		  <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> または
		  これらはパッケージが順に <em>non-US/main</em>、
		  <em>non-US/contrib</em> 及び
		  <em>non-US/non-free</em> セクションに属する場合です。

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

	  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
	  それそれのパッケージには所定の <em>priority</em> (優先度)
	  に含まれています。この情報は Debian


	  The following <em>priority levels</em> are recognised by the
	  Debian package management tools.
	  Debian パッケージ管理システムが認識する <em>priority</em> の値
		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> なパッケージのみのシステムはおそらく実用的ではないでしょうが、システム管理者がシステムを起動し、より多くのソフトウェアをインストールするに足るだけの機能は備えています。
		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.
		    This is an important criterion because we are
		    trying to produce, amongst other things, a free
		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 ライクなシステムに於いても見つかることが期待されるような重要なプログラムはこのプライオリティに属します。
		<tt>important</tt> に含まれるべき
		    Unix を創ろうとしているわけですから、これは重要な基準です。
		このカテゴリには Emacs、X ウィンドウシステム、TeX
		といった大規模なアプリケーションは <em>含まれません</em>。
		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.
		と十分実用的な TeX および LaTeX のサブセットが含まれます。
		(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 しないようにすべきです。

		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
		プライオリティとして required、important、standard、optional

	  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.

      <heading>Binary packages</heading>
	  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 ディストリビューションに含まれる全てのパッケージは

	<heading>The package name</heading>
	    Every package must have a name that's unique within the Debian
	    全てのパッケージは Debian アーカイブ内において重複しない名前を持っていなければなりません。

	    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.

	    The package name is part of the file name of the
	    <tt>.deb</tt> file and is included in the control field
	    パッケージ名は <tt>.deb</tt> ファイルのファイル名の一部であり、

	<heading>The maintainer of a package</heading>
	    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 メンテナ
	    (たとえばメーリングリスト) で連絡の取れるグループであっても構いません) を持たなければなりません。

 	    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> フィールドに異なった形式の名前と電子メールアドレスを記入することは避けるべきです。

	    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 グループ
	    このようなパッケージは <em>orphaned パッケージ</em>
	    <!-- 別にプロジェクトをやめなくともメンテナは降りられるので、
	    この書き方は勇み足 -->
		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
		or from the <url
		name="Debian Developer's Reference"> webpage.-->
		これを丁寧に行うやり方の詳細は Debian Developer's
		Reference (開発者の手引き) に書かれています。この手引きは、
		<tt>developers-reference</tt> パッケージ、または Debian FTP
		サーバ <ftpsite>ftp.debian.org</ftpsite> の
		そして <url id="http://www.debian.org/doc/packaging-manuals/developers-reference/";
		name="Debian Developer's Reference">

	<heading>The description of a package</heading>
	    Every Debian package must have an extended description
	    stored in the appropriate field of the control record.
	    全ての Debian パッケージには、コントロールファイル中の適切なフィールドに詳細な説明文が記入されていなければなりません。
	    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 &#45;&#45; that is what installation scripts,
	    manual pages, info files, etc., are for.  Copyright
	    statements and other administrivia should not be included
	    either &#45;&#45; that is what the copyright file is for.</p>
	    それら向けには copyright ファイルが用意されています。


	    Every package must specify the dependency information
	    about other packages that are required for the first to
	    work correctly.
	    For example, a dependency entry must be provided for any
	    shared libraries required by a dynamically-linked executable
	    binary in a package.
	    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"> 参照)
	    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> エントリを指定しなければなりません。
	    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>Pre-Depends</tt> エントリを指定するべきではありません。
	<sect1 id="virtualpackage">
	<heading>Virtual packages</heading>
	    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&#45;&#45;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> します。
	    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

	    The latest version of the authoritative list of virtual
	    package names can be found on
	    <ftpsite>ftp.debian.org</ftpsite> in
	    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.
	    この一覧は <tt>debian-policy</tt> パッケージにも含まれています。


	<heading>Base packages</heading>
	  <heading>Base パッケージ</heading>
	    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> セクションへの収録を認められています。

	    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"> 参照) が付加されているでしょう。
	    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>base</tt> セクションに収めてはいけません。


	<sect1 id="essential">
	<heading>Essential packages</heading>
	  <heading>Essential パッケージ</heading>
	    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>

	    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>&#45;&#45;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> 指定をしてはいけません。
	    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
            dpkg は <tt>Essential</tt> パッケージが未設定な状態でも他のパッケージのアップグレードを止めることはありませんので、
            <tt>Essential</tt> パッケージはすべて、未設定状態でも基本機能はすべて提供している必要があります。
            <tt>Essential</tt> 指定を行ってはいけませんし、そのパッケージに依存する他のパッケージは明示的に適切な依存関係フィールドを与えなければいけません。
	    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
	    <tt>debian-devel</tt> メーリングリストで議論して同意が得られない限り、パッケージに <tt>Essential</tt> 指定を付加してはなりません。


	<heading>Maintainer scripts</heading>
	    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>&#45;&#45;quiet</tt> option on
	    中でも、<prgn>install-info</prgn> を使うときは
	    <tt>--quiet</tt> オプションを使いましょう。
	    Errors which occur during the execution of an installation
	    script should be checked and the installation
	    should not continue after an error.
	    Note, that <ref id="scripts">, in general applies to
	    package maintainer scripts, too.
	    全体として <ref id="scripts"> の内容はパッケージのメンテナスクリプトにも適用されます。
	    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> を使うべきではありません。
	    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> &#45; this is an exception to
	    the usual rule that versioned conflicts should be
	    「共通の」コマンド名 (あるいは、一般的にファイル名)
	    を使って同時に (複数の実装が) インストールできるようにすべきです。
	    (まだ) <prgn>update-alternatives</prgn>
	    <tt>Conflicts</tt> を使わなければいけません。
	    (この場合に限って、以前の <prgn>update-alternatives</prgn>
	    を使っていなかったバージョンに対する Conflict
	    <!-- <heading>Prompting in maintainer scripts</heading>-->
	      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
	      or on your local mirror. -->
	      (例えば <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> にも置かれています
		  2.5% of Debian packages [see <url
		  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
		  they include preconfiguration, (mostly)
		  noninteractive installation, elimination of
		  redundant prompting, consistency of user interface,
		  現時点で 2.5 % の Debian パッケージがインストール時に debconf
		  を使っています [<url id="http://kitenet.net/programs/debconf/stats/";>]。
		  またその数は毎日増加しています。debconf を使う利点は
		  <url id="http://kitenet.net/doc/debconf-doc/introduction.html";>;
		  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
		  <package>debconf</package> を使ったパッケージ数の増加と、Debian
		  設定管理システムの第二版 (<package>cdebconf</package>)
	      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> パッケージに属するツールのみを
		  <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>
	      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

	    適切な共有の設定ファイル (例えば <tt>/etc/papersize</tt> や
	    <tt>/etc/news/server</tt> のような) や <package>debconf</package>

	    It also means that an upgrade should not ask the same
	    questions again, unless the user has used <tt>dpkg
	    &#45;&#45;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
	    <tt>dpkg --purge</tt> を使っていない限り、同じ質問を二度するべきではないということも意味します。

	    <tt>/etc</tt> 内の適切な場所に保存されていなければならず、またこれがどうされたかは文書化されているべきです。
	      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
	      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> スクリプトにて表示し、ユーザにリターンキーを押して承認するよう質問するべきです。
	    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
	    どんな必要な質問も、たいていの場合は <prgn>config</prgn> か
	    <prgn>postinst</prgn> スクリプトからに限られるべきです。
	    そして質問が <prgn>postinst</prgn> 中で行われていた場合、パッケージのインストールが失敗して
	    <prgn>postinst</prgn> が <tt>abort-upgrade</tt>、
	    <tt>abort-remove</tt>、あるいは <tt>abort-deconfigure</tt>
      <heading>Source packages</heading>
	<sect1 id="standardsversion">
	<heading>Standards conformance</heading>
	    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; です。

	    This information may be used to file bug reports
	    automatically if your package becomes too much out of
	    The version number has four components&#45;&#45;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 つの数字からなります。
	    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
		In the past, people specified the full version number
		in the Standards-Version field, for example `'.
		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
		以前はバージョンを指定するのに、`' という様に常に
		3 つの数字、この例では `2.3.0'、でバージョンを示すようにしたほうが、より良いだろうと思われるからです。
		ただし、4 つ使いたければ使ってもかまいません。
	    </footnote> です。
	    <!-- 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.
		See the file <tt>upgrading-checklist</tt> for
		information about policy which has changed between
		different versions of this document.
	    <TT>Standards-Version</TT> を変更してリリースするべきです。
		<tt>upgrading-checklist</tt> ファイルを参照ください。

	  <!-- <heading>Package relationships</heading> -->
	  <heading> パッケージ同士の依存関係</heading>
	    <!-- 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. -->
	    <!-- 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>
		    <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).-->
		      これによって、このリストはポリシー関連文書とは別に管理されます (このリストはポリシー関連文書に必要な厳密な管理を行う必要はないので)。
		      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
		      build-essential なパッケージを依存関係によってインストールすることができますし、同時に他のパッケージ
		      (例えばタスクパッケージ) から build-essential
		      The separate package allows bug reports against
		      the package to be categorized separately from
		      the policy management process that uses the BTS-->
		      BTS を使ったポリシー管理プロセスとは分けて考える必要があります。
	    </footnote> にリストアップされています。

	    <!-- 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.
		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.
		<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> パッケージをインストールすることで、実行時の依存関係が満たされることは自動的に保証されます。

	    <!-- 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.
	  <!-- <heading>Changes to the upstream sources</heading> -->

	    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
	    ソースコードへの変更が Debian

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

	    <!-- 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"> を参照)。


	    <!-- 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> を変更すれば、だれもそのあとでパッケージの再ビルドができなくなってしまいます。

	  <heading>Documenting your changes</heading>
            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 エントリを作成することにするほうがよりよい方法です。)

	    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>.
		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.)
	    experimental ではないパッケージにおいては、
	    <tt>debian/changelog</tt> の書式としては、最新リリースの
	    <prgn>dpkg</prgn> がサポートしているものを使わなければなりません。
		このパーザは <prgn>dpkg-genchanges</prgn> および
		<prgn>dpkg-gencontrol</prgn> が期待しているものと API
		新しい書式が広く関心を引く (であろう) ものであるときには、
		<prgn>dpkg</prgn> のメンテナに連絡をとり、その書式に対応するパーサを
		<prgn>dpkg</prgn> パッケージに含めてもらうようにして下さい。
		(そのパーサとマニュアルページは、<prgn>dpkg</prgn> の一部として
		dpkg の他の部分同様 GNU GPL で配付することを認める必要があります)。

	  <heading>Error trapping in makefiles</heading>
	  <heading>makefile でのエラーを捕捉する</heading>
	    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
            <prgn>make</prgn> が makefile (あなたのパッケージの上流が用意した
	     makefile も <tt>debian/rules</tt> も含む)
	    で指定されたコマンドを呼び出す際には、<tt>sh</tt> を使います。
            このため、<tt>sh</tt> のエラー処理の出来が悪いという欠点が露呈してしまいます。
	    あなたの makefile に、そこから呼び出されるコマンドの一つとして小さなスクリプトが含まれている場合、

	    <prgn>make</prgn> は問題が起こった後ものんきに処理を続けてしまうでしょう。
	    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>&amp;&amp;</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>&amp;&amp;</tt> でつなげば十分でしょう。
	    makefile コマンドのそれぞれの先頭に独立した <tt>set -e</tt>

	<heading>Obsolete constructs and libraries</heading>

	    The include file <prgn>&lt;varargs.h&gt;</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>&lt;varargs.h&gt;</prgn>

            (古いプログラムか、あるいは Netscape
	    Debian packages should be patched to use
	    <prgn>&lt;stdarg.h&gt;</prgn> and <tt>ncurses</tt>
	    Debian 用パッケージは、上記ファイルではなく
	    <prgn>&lt;stdarg.h&gt;</prgn> と <tt>ncurses</tt>

    <!-- <chapt id="controlfields"><heading>Control files and their fields</heading>-->
    <chapt id="controlfields"><heading>コントロールファイルと、その各フィールド</heading>
	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
	このデータは多くの場合、<em>コントロールファイル</em> 中に格納されます。
	<tt>.changes</tt> ファイルを持っています。
	また、<prgn>dpkg</prgn> の内部のデータベースも同様のフォーマットです。
      <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>	<!--
	  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:
	    Package: libc6
	  the field name is <tt>Package</tt> and the field value
	  水平方向の空白 (スペース、およびタブ) は、値の前後に置くことができ、無視されます。
	    Package: libc6
	  この場合、フィールド名は <tt>Package</tt> で、フィールドの値は
	  <tt>libc6</tt> です。

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

	<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

	<p>	  <!--
	  Field names are not case-sensitive, but it is usual to
	  capitalize the field names using mixed case as shown below.-->

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

      <sect><heading><!-- List of fields-->フィールドのリスト</heading>
	  This list here is not supposed to be exhaustive. Most fields
	  are dealt with elsewhere in this document.-->
	<sect1 id="f-Package"><heading><tt>Package</tt>

	  <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>	   <!--
	    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>-->
	    作成しようとしているパッケージ (または他フィールドで参照しているもの)

	<sect1 id="f-Version"><heading><tt>Version</tt>

	  <p>	<!--
	    This lists the source or binary package's version number -
	    see <ref id="versions">.-->
	    <ref id="versions"> を参照ください。



	  <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"> の項を参照ください。

	<sect1 id="f-Distribution"><heading><tt>Distribution</tt>
	  <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
	    (複数ある場合は空白で区切られて) 含まれます
		<!-- Current distribution names are:-->
		    <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 になります)。

		      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> へ収録されます。

		      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
		      このディストリビューション名は Debian
		      unstable ディストリビューションからのパッケージを、
		      unstable 中で大きな問題が発生しないことを確認する短い猶予期間をおいて、受け入れます。
		      これは unstable よりは問題が起こる可能性は少ないでしょうが、危険性は残っています。
		      パッケージを直接 <em>testing</em>

		      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 でしょうが……… -->

		      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
		<!-- You should list <em>all</em> distributions that the
		package should be installed into.-->
		このフィールドには、そのパッケージがインストールされる、<em>すべて</em> のディストリビューションを列挙しなければいけません。


    <!--<chapt id="versions"><heading>Version numbering </heading>-->
    <chapt id="versions"><heading>Version <!--numbering -->番号付け</heading>

	Every package has a version number recorded in its
	<tt>Version</tt> control file field.-->
	全てのパッケージは、コントロールファイルの <tt>Version</tt> フィールドにバージョン番号を持っています。

      <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.-->
	バージョン番号の形式は (比較に関する限り)

	<!-- The version number format is:-->バージョン番号のフォーマットは、

	<!-- The three components here are:-->バージョンを構成する 3 つの要素は

	      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.-->
	      <var>upstream_version</var> にコロンを含めてはいけません。

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



	      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
	       <tt>.deb</tt> ファイルが作られたオリジナルの (`上流の')

	    <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>	      <!--
	      The <var>upstream_version</var> may contain only
		<p>Alphanumerics are <tt>A-Za-z0-9</tt> only.</p>
	      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
	      <var>upstream_version</var> は英数字
		<p>英数字は <tt>A-Za-z0-9</tt> のみです。</p>
	      と文字 <tt>.</tt> <tt>+</tt>
	      <tt>-</tt> <tt>:</tt> (ピリオド、プラス、ハイフン、コロン)
	      ただし、<var>debian_revision</var> がない場合、ハイフンは許されません。
	      また、<var>epoch</var> がない場合、コロンは許されません。


	      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> (プラスとピリオド)

	    <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>	      <!--
	      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>	      <!--
	      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> がないものは、それがあるものより以前のものであるとして比較されます
	<!-- 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> の部分はパッケージ管理システムから同じアルゴリズムを用いて比較されます。

	<!-- The strings are compared from left to right.-->

      <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.-->
	両方の文字列に対する、この数字でない部分 (そのうちの一つは空であっても構いません) を辞書順で比較します。もし違いが見つかれば、それを返します。
	ここでの辞書順とは、すべての文字が非文字より先に来る様に修正した ASCII 順です。

      <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>	<!--
	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.-->
	(先頭から、最初の非数字の文字列と最初の数字の文字列を比較し、切り離しながら) 繰り返します。

      <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>	<!--
	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> フィールドではまともな形式に変換すべきです。

	<heading><!-- Version numbers based on dates-->日付に基づくバージョン番号</heading>
	  In general, Debian packages should use the same version
	  numbers as the upstream sources.-->
	 一般的に、Debian パッケージは上流ソースと同じバージョン番号を使うべきです。

	  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'

	  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,
	  そのような場合に、今後の新しい上流バージョンに対して epoch を使わなくて済むようにするためには、バージョン番号を `19960501'、`19961224'

	  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> ことに注意して下さい。

	  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' という書式を使うべきです。

    <chapt id="miscellaneous"><heading><!--Packaging Considerations-->パッケージング時の考慮点</heading>

      <sect id="timestamps"><heading><!--Time Stamps-->タイムスタンプ</heading>
	  Maintainers should preserve the modification times of the
	  upstream source files in a package, as far as is reasonably
	  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. -->
	      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

      <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>	    <!--
	  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' という名前で実行できるようにする為です。

	  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> のことです。

	  <!-- The targets which must be present are:	   -->
		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.)
		パッケージの構築 (ビルド)、すなわち全てのパッケージの非対話的な設定とコンパイルを行ないます。

	      <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> ターゲットで、各々のやり方でパッケージをビルドして、それぞれに対応したバイナリパッケージを生成することになります。


		The <prgn>build</prgn> target must not do anything
		that might require root privilege.-->
		ルート権限が必要なことを <prgn>build</prgn> ターゲットで実行してはいけません。

	      <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>		  <!--
		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
		    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
		</footnote> -->
		があまり良く設計されていない時、 または <prgn>build</prgn> の前に
		<prgn>clean</prgn>  の実行が必要な時、ビルドプロセスの終了時に
		<tt>touch build</tt> を実行しておくのがよいでしょう。
		これによって、<tt>debian/rules build</tt> が再度実行されたときに、プログラム全体を再ビルドしなくてすみます
		    <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> のドキュメントを参照ください。

	    <tag><tt>binary</tt>, <tt>binary-arch</tt>,
		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>		  <!--
		<prgn>binary</prgn> may be (and commonly is) a target
		with no commands which simply depends on
		<prgn>binary-arch</prgn> and
		<prgn>binary</prgn> は、コマンドなしで単純に
		<prgn>binary-arch</prgn> と <prgn>binary-indep</prgn>

		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
		両方の <prgn>binary-*</prgn> ターゲットは、 <prgn>build</prgn> ターゲットに依存すべきです。
		そしてその後 <prgn>dpkg-gencontrol</prgn> を使ってコントロールファイルを作成し、<prgn>dpkg-deb</prgn> でビルドを行って関連したバイナリパッケージを生成し、それをトップレベルディレクトリの親ディレクトリ中に置くべきです。

	      <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>		  <!--
		The <prgn>binary</prgn> targets must be invoked as
		    The <prgn>fakeroot</prgn> package often allows one
		    to build a package correctly even without being
		<prgn>binary</prgn> ターゲットは、ルート権限で起動されなければ


		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>		  <!--
		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>	<!--
		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
		<prgn>build</prgn> ターゲットがルート権限で実行されたあと、及び <prgn>binary</prgn> ターゲットが実行された後には、<prgn>clean</prgn>
		(例えば、<prgn>clean</prgn>  はディレクトリを作成することもあるからです)。

	    <tag><tt>get-orig-source</tt> (optional)</tag>

	      <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>		  <!--
		This target may be invoked in any directory, and
		should take care to clean up any temporary files it
		may have left.-->

	      <p>		  <!--
		This target is optional, but providing it if
		possible is a good idea.-->
		このターゲットはオプションです。 しかしできる限りつけた方がよいでしょう。

	  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>	    <!--
	  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> に他のターゲットを置くことは許されます。

	  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>make</prgn> 変数を設定することによって決定されます。
	  これにより、ホストマシン (パッケージの作成対象としているマシンタイプ)
	  (ビルド作業に使っているマシン) の Debian 形式のアーキテクチャと
	  GNU 形式のアーキテクチャ指定文字列を得ることができます。
	  次に、サポートされている <prgn>make</prgn> 変数を示します。
	  <list compact="compact">
	      <p><tt>DEB_*_ARCH</tt> <!--(the Debian architecture)-->(Debian 形式のアーキテクチャ)</p>
	      <p><tt>DEB_*_GNU_TYPE</tt> <!-- (the GNU style architecture
		specification string)-->(GNU 形式アーキテクチャ指定文字列)</p>
	      <p><tt>DEB_*_GNU_CPU</tt> (the CPU part of
	      <p><tt>DEB_*_GNU_CPU</tt> (<tt>DEB_*_GNU_TYPE</tt> の CPU の部分)</p>
 	      <p><tt>DEB_*_GNU_SYSTEM</tt> (the System part of
	      <p><tt>DEB_*_GNU_SYSTEM</tt> (<tt>DEB_*_GNU_TYPE</tt> の システムの部分)</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> の場合にはホストマシンの指定になります。

	  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> のドキュメントを参照して下さい。

	  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 書式の変数を使わなくてはいけません。

      <sect id="dpkgchangelog"><heading><tt>debian/changelog (変更履歴)</tt>

	<p>	    <!--
	  This file records the changes to the Debian-specific parts of the
	  このファイルは、パッケージの Debian 特有の部分の変更を
	      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>	    <!--
	  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.

	  <!--That format is a series of entries like this:	-->
<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>
 &#45;&#45; <var>maintainer name and email address</var>  <var>date</var>
<var>パッケージ名</var> (<var>バージョン</var>) <var>ディストリビューション</var>; urgency=<var>緊急度</var>

  * <var>変更内容</var>
  * <var>また別の変更内容</var>

 -- <var>メンテナ名と電子メールアドレス</var>  <var>日付</var>

	  <!-- <var>package</var> and <var>version</var> are the source
	  package name and version number.-->
	  <var>package</var> と <var>version</var> は ソースパッケージの名前とバージョンです。

	  <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"> をご覧ください。

	  <!-- <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>,
	      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.
	  <var>urgency</var> は、アップロード時の <tt>.changes</tt>
	  ファイルの <tt>Urgency</tt> フィールドとして使われる値です。
	  <prgn>dpkg</prgn> の changelog フォーマットでは、コンマは
	  (しかしながら、現在のところ <var>keyword</var>として有効なものは
	      通常、<tt>urgency</tt> のとる値は <tt>low</tt>、<tt>medium</tt>、
	      <tt>high</tt> と <tt>critical</tt> です。
	      これはパッケージをどのぐらい急いで <tt>testing</tt>

	<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>	    <!--
	  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.
	      To be precise, the string should match the following
	      Perl regular expression (where $pound=<tt>#</tt>;):
		<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.
	      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.
	  このアップロードがバグトラッキングシステム (BTS)
	  で記録されたバグを修正するものならば、changelog 中に
	  <tt>closes: Bug#<var>nnnnn</var></tt>
	      より正確には、以下の Perl 正規表現にマッチするような文字列です。ここで $pound=<tt>#</tt>
		<p>この正規表現中で $pound 変数を導入しているのは、
		  "#" で混乱してうまく処理できないためです。
	      列挙されたバグ番号はアーカイブメンテナスクリプト (<prgn>katie</prgn>)
	      で閉じられるか、NMU の場合には fixed とのマークが付けられます。
	  の文字列を含めることで、パッケージが Debian

	  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>

	  <!-- The <var>date</var> should be in RFC822 format -->
	  <var>日付</var> は RFC822 フォーマット
	      This is generated by the <prgn>822-date</prgn>
	      これは <prgn>822-date</prgn> プログラムで作成します。
	    <p> 訳注: RFC2822 参照。</p>
	  <!--; it should include the time zone specified
	  numerically, with the time zone name or abbreviation
	  optionally present as a comment in parentheses.-->

	<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 みたい -->

	<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
	  <p>	      <!--
	    A changelog parser must not interact with the user at
	    changelog パーサはユーザとの対話的処理を一切行ってはなりません。
	    <!-- パッケージングマニュアルからは相当削除あり -->

      <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>	    <!--
	  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>
	  <tt>debian/substvars</tt> ファイルは通常 <tt>debian/rules</tt>
	  <prgn>clean</prgn> ターゲットによって削除しておかなければいけません。

	  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"> をご覧ください。

      <sect id="debianfiles"><heading><tt>debian/files</tt>

	<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>	    <!--
	  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> 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
	      <tt>files.new</tt> は <prgn>dpkg-gencontrol</prgn> と <prgn>dpkg-distaddfile</prgn> が一時的なファイルとして使います。
	      エラーが起こったときに壊れたファイルをそのまま残しておかないようにするため、新しいバージョンの <tt>files</tt>
	  </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>	    <!--
	  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
	  &#45;&#45;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-deb --build</prgn>
	  をバイナリパッケージ作成のため実行した場合に作成される <tt>.deb</tt>
	  のためのエントリを <tt>debian/files</tt> に追加します。

	<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>.-->
	  そして、<tt>debian/files</tt> のリストにファイルを追加するために
	  <prgn>dpkg-distaddfile</prgn> を呼ぶようにすべきです。

      <sect id="restrictions"><heading><!--Restrictions on objects in source packages-->ソースパッケージに含まれるものに対する制限

	<p>	    <!--
	  The source package may not contain any hard links-->
	      This is not currently detected when building source
	      packages, but only when extracting
	      Hard links may be permitted at some point in the
	      future, but would require a fair amount of
	  </footnote><!--, device special files, sockets or setuid or
	  setgid files.-->
	  、デバイスファイル、ソケットファイル、及び setuid や setgid
	      <!--Setgid directories are allowed.-->
	      setgid されたディレクトリーは許されます。
      <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) の情報も示されているべきです。

	<sect1><heading><!--Notes about writing descriptions-->

	  <p>	  <!--
	    The single line synopsis should be kept brief - certainly
	    under 80 characters.  -->
	    一行による要約は簡潔にすべきです。半角換算で 80 文字以下としてください。

	  <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>	  <!--
	    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
	    また要約 (一行の) のみが表示されているときには意味をなしません。

	  <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>	  <!--
	    The description field needs to make sense to anyone, even
	    people who have no idea about any of the things the
	    package deals with.-->
		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>	  <!--
	    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>	  <!--
	    You may include information about dependencies and so forth
	    in the extended description, if you wish.-->

	  <p>	  <!--
	    Do not use tab characters.  Their effect is not predictable.-->


    <!-- <chapt id="maintainerscripts"><heading>Package maintainer scripts
	and installation procedure
    <chapt id="maintainerscripts"><heading><!--Package maintainer scripts
	and installation procedure-->パッケージ管理スクリプトとインストールの手順

      <sect><heading><!--Introduction to package maintainer scripts-->パッケージ管理スクリプトへの手引き

	<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>	  <!--
	  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>#!</tt> で始めなくてはなりません。

	<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
	  エラーがあった場合にはスクリプトが 0
	  シェルスクリプトでは <em>ほとんど常に</em> <tt>set -e</tt>
	  を使う必要があるということを意味します (実際には、
	  もちろん、全てがうまくいった場合に、0 でないステータスで終了しないことも重要です。
	<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>	  <!--
	  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>postrm</prgn> は削除された後に呼び出されます。

	<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>install-info</prgn> や <prgn>update-rc.d</prgn>
	  などのプログラムが指定された <tt>PATH</tt>
	  管理スクリプトは <tt>PATH</tt> をリセットすべきではありませんが、
	  <tt>PATH</tt> の前か後に、パッケージに対して特別なディレクトリを付け加えるという方法を採るのはかまいません。

	<heading><!-- Maintainer scripts Idempotency-->メンテナスクリプトの再入結果の同一性</heading>

	  <!-- It is very important to make maintainer scripts
	<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
	      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
	      これがそうあるべきなのは、ユーザからの <prgn>dpkg</prgn>
	      <prgn>dpkg</prgn> が処理を再実行しようとした場合、ひどく壊れたパッケージを残さないようにするためです。

	<heading><!-- Controlling terminal for maintainer scripts-->メンテナスクリプトからのターミナルの制御</heading>

	  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
	  <tt>/dev/tty</tt> を介して行うべきです。これは <prgn>dpkg</prgn>
	  <tt>$|=1</tt> と設定してバッファなし出力モードにすべきです。

	  Each script should return a zero exit status for
	  success, or a nonzero one for failure.-->
	  各スクリプトは成功の場合には終了ステータスを 0 に、失敗の場合には
	  0 でない値にして帰ってください。

      <sect id="mscriptsinstact"><heading><!-- Summary of ways maintainer
	  scripts are called-->

	  <list compact="compact">
	      <p><var>new-preinst</var> <tt>install</tt></p>
	      <p><var>new-preinst</var> <tt>install</tt>
	      <p><var>new-preinst</var> <tt>upgrade</tt>
	      <p><var>old-preinst</var> <tt>abort-upgrade</tt>

	  <list compact="compact">
	      <p><var>postinst</var> <tt>configure</tt>
	      <p><var>old-postinst</var> <tt>abort-upgrade</tt>
	      <p><var>conflictor's-postinst</var> <tt>abort-remove</tt>
		<tt>in-favour</tt> <var>package</var>
		<tt>abort-deconfigure</tt> <tt>in-favour</tt>
		<var>failed-install-package</var> <var>version</var>
		<tt>removing</tt> <var>conflicting-package</var>

	  <list compact="compact">
	      <p><var>prerm</var> <tt>remove</tt></p>
	      <p><var>old-prerm</var> <tt>upgrade</tt>
	      <p><var>new-prerm</var> <tt>failed-upgrade</tt>
	      <p><var>conflictor's-prerm</var> <tt>remove</tt>
		<tt>in-favour</tt> <var>package</var>
		<var>deconfigured's-prerm</var> <tt>deconfigure</tt>
		<tt>in-favour</tt> <var>package-being-installed</var>
		<var>version</var> <tt>removing</tt>

	  <list compact="compact">
	      <p><var>postrm</var> <tt>remove</tt></p>
	      <p><var>postrm</var> <tt>purge</tt></p>
		<var>old-postrm</var> <tt>upgrade</tt>
	      <p><var>new-postrm</var> <tt>failed-upgrade</tt>
	      <p><var>new-postrm</var> <tt>abort-install</tt></p>
	      <p><var>new-postrm</var> <tt>abort-install</tt>
	      <p><var>new-postrm</var> <tt>abort-upgrade</tt>
		<var>disappearer's-postrm</var> <tt>disappear</tt>

      <sect id="unpackphase"><heading><!-- Details of unpack phase of
	  installation or upgrade-->

	<p>	  <!--
	  The procedure on installation/upgrade/overwrite/disappear
	  (i.e., when running <tt>dpkg &#45;&#45;unpack</tt>, or the unpack
	  stage of <tt>dpkg &#45;&#45;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
	   インストール/アップグレード/上書き/消去 (すなわち、
	   <tt>dpkg --unpack</tt> が走っているとき、または
	   <tt>dpkg --install</tt> の展開段階のとき)
	   もしエラーが起これば (下記の場合を除けば) そこでの動作は、一般に逆方向へ走る処理です。
		    <p><!-- If a version of the package is already
		      installed, call-->
			<var>old-prerm</var> upgrade <var>new-version</var>
		      If the script runs but exits with a non-zero
		      exit status, <prgn>dpkg</prgn> will attempt:-->
		      もし、これがエラーとなったら (つまり、
		      <prgn>dpkg</prgn> はかわりに次の呼び出しをします。
			<var>new-prerm</var> failed-upgrade <var>old-version</var>
		      <!-- Error unwind, for both the above cases:-->
			<var>old-postinst</var> abort-upgrade <var>new-version</var>
	      <p><!-- If a `conflicting' package is being removed at the same time:-->
		      If any packages depended on that conflicting
		      package and <tt>&#45;&#45;auto&#45;deconfigure</tt> is
		      specified, call, for each such package:-->
		      <tt>--auto-deconfigure</tt> が指定されているならば、
			<var>deconfigured's-prerm</var> deconfigure \
			in-favour <var>package-being-installed</var> <var>version</var> \
			removing <var>conflicting-package</var> <var>version</var>
		      <!-- Error unwind:-->このときのエラー回復は
			<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>
		      <!-- The deconfigured packages are marked as
		      requiring configuration, so that if
		      <tt>&#45;&#45;install</tt> is used they will be
		      configured again if possible.-->
		      です。もし、<tt>--install</tt> が使われたばあいに再設定可能としておくため、
		    <p><!-- To prepare for removal of the conflicting package, call:-->
			<var>conflictor's-prerm</var> remove in-favour <var>package</var> <var>new-version</var>
		      <!-- Error unwind:-->このときのエラー回復は
			<var>conflictor's&#45;postinst</var> abort&#45;remove \
			in-favour <var>package</var> <var>new-version</var>
		    <p><!-- If the package is being upgraded, call:-->
			<var>new-preinst</var> upgrade <var>old-version</var>
		      Otherwise, if the package had some configuration
		      files from a previous version installed (i.e., it
		      is in the `configuration files only' state):-->
			<var>new-preinst</var> install <var>old-version</var>

		    <p><!-- Otherwise (i.e., the package was completely purged):-->
		    そうでもない (つまり、そのパッケージが完全削除されていた)
			<var>new-preinst</var> install
		      <!-- Error unwind actions, respectively:-->
			<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

		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>		<!--
		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>&#45;&#45;force-overwrite</tt> flag is
		enabled, downgrading it to a warning, but this may not
		always be the case.-->
		(<ref id="replaces"> 参照)
		<tt>&#45;&#45;force-overwrite</tt> フラグが有効にされており、このエラーは警告に格下げされています。

	      <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>&#45;&#45;force-overwrite-dir</tt>, but this is not
		そのパッケージが普通のファイルやほかのディレクトリでないような内容物を含んでいた場合です (ここでも、<tt>Replaces</tt>
		 <tt>--force-overwrite-dir</tt> を使ってこのエラーを無効にすることができますが、これは勧められません。

	      <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.-->
		    Part of the problem is due to what is arguably a
		    bug in <prgn>dpkg</prgn>.-->
		</footnote> が起こります。

	      <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
		そのかわりに、現在ある状態 (シンボリックリンクであるのか否か)
		はそのままにされて、シンボリックリンクの場合 <prgn>dpkg</prgn>


		    <p><!-- If the package is being upgraded, call-->
			<var>old-postrm</var> upgrade <var>new-version</var>
		    <p><!-- If this fails, <prgn>dpkg</prgn> will attempt:-->
		    もしこれに失敗したら、<prgn>dpkg</prgn> は次の呼び出しを試みます。
			<var>new-postrm</var> failed-upgrade <var>old-version</var>
		      <!-- Error unwind, for both cases:-->
			<var>old-preinst</var> abort-upgrade <var>new-version</var>
		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> は戻ることのできない作業を始める時です。
	      <p>		<!--
		Any files which were in the old version of the package
		but not in the new are removed.-->
	      <p><!-- The new file list replaces the old.-->
	      <p><!-- The new maintainer scripts replace the old.-->

	        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-->
		    <p><prgn>dpkg</prgn> <!-- calls:-->は次の呼び出しを行います。
			<var>disappearer's-postrm</var> disappear \
			<var>overwriter</var> <var>overwriter-version</var>
		    <p><!-- The package's maintainer scripts are removed.-->
		      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
		      <prgn>dpkg</prgn> によって削除されるのではなく、無視されます)。
		      <prgn>dpkg</prgn> は前もって、そのパッケージが削除されそうなのかどうかを知らないので、
		      削除されるパッケージの `prerm' は 呼び出されないということに注意してください。
		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.)-->
		The backup files made during installation, above, are

		The new package's status is now sane, and recorded as

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

		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).-->

      <sect><heading><!-- Details of configuration-->設定の詳細</heading>

	  <!-- When we configure a package (this happens with <tt>dpkg
	    &#45;&#45;install</tt>, or with <tt>&#45;&#45;configure</tt>), we first
	  update any <tt>conffile</tt>s and then call: -->
	  パッケージを設定する (この状況は <tt>dpkg --install</tt> や
	  <tt>--configure</tt> で起きます) とき、まず <tt>conffile</tt>
	    <var>postinst</var> configure <var>most-recently-configured-version</var>

	<p>	  <!--
	  No attempt is made to unwind after errors during

	<p>	  <!--
	  If there is no most recently configured version
	  <prgn>dpkg</prgn> will pass a null argument; older versions
	  of dpkg may pass <tt>&lt;unknown&gt;</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>&lt;unknown&gt;</tt>
	  を (不等号も含めて) 渡すかもしれません。さらに古いバージョンの
	  <prgn>dpkg</prgn> は、どのような状況においても二番目の引数は何も渡しません。

      <sect><heading><!--Details of removal and/or configuration purging-->

		  <var>prerm</var> remove
		The package's files are removed (except <tt>conffile</tt>s).-->
		パッケージのファイルを (<tt>conffile</tt> 群を除いて) 削除します。
		  <var>postrm</var> remove
		All the maintainer scripts except the <tt>postrm</tt>
		are removed.-->
	        <tt>postrm</tt> 以外のメンテナスクリプトを全て削除します。

	      <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> の状態以外に違いが無いので、自動的に完全削除されることに注意してください。
		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> など) が削除されます。
		  <var>postrm</var> purge
	      <p><!-- The package's file list is removed.-->
	  No attempt is made to unwind after errors during

    <chapt id="relationships"><heading><!-- Declaring relationships between

      <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>	<!--
	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>Provides</tt> 及び <tt>Replaces</tt> フィールドを使用します。

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

        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> フィールドを使用します。

      <sect id="depsyntax"><heading><!-- Syntax of relationship fields-->

	<p>	  <!--
	  These fields all have a uniform syntax.  They are a list of
	  package names separated by commas.-->

          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>	  <!--
	  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>	  <!--
	  The relations allowed are <tt>&lt;&lt;</tt>, <tt>&lt;=</tt>,
	  <tt>=</tt>, <tt>&gt;=</tt> and <tt>&gt;&gt;</tt> for
	  strictly earlier, earlier or equal, exactly equal, later or
	  equal and strictly later, respectively.  The forms
	  <tt>&lt;</tt> and <tt>&gt;</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>&lt;=</tt>、<tt>=</tt>、<tt>&gt;=</tt> 及び <tt>&gt;&gt;</tt>
	  記号 <tt>&lt;</tt> と <tt>&gt;</tt> はそれぞれ「以下」「以上」
	  <tt>&lt;</tt> と <tt>&gt;</tt> は使うべきではありません
	  (<prgn>dpkg</prgn> はまだこの書式をサポートしてはいます)。

	<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> の変更を見越して、

	  <!-- For example:-->例を次に示します。
	    Package: metamail
	    Version: 2.7-3
	    Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh

          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-Conflicts</tt> 及び <tt>Build-Conflicts-Indep</tt>)
	  角括弧ではさんで指定します。角括弧のなかには、空白で区切られた Debian
	  アーキテクチャの名前のリストを入れます。感嘆符 (!)
	  もし、現在の Debian ホストのアーキテクチャがこのリストに無く、感嘆符のついた指定も無い場合、もしくは感嘆符付きでこのリスト中にある場合には、

	  <!-- For example:-->例を次に示します。
	    Source: glibc
	    Build-Depends-Indep: texinfo
	    Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
	    hurd-dev [hurd-i386], gnumach-dev [hurd-i386]

        <heading><!-- Binary Dependencies - <tt>Depends</tt>,
          <tt>Recommends</tt>, <tt>Suggests</tt>, <tt>Enhances</tt>,
          バイナリの依存関係 - <tt>Depends</tt>、

	<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>	  <!--
	  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
	  <tt>Pre-Depends</tt> と <tt>Conflicts</tt>
	  (これらについては以降の節で説明します) 以外のすべての宣言は、
	  パッケージを <em>設定する時にだけ</em> 有効です。依存関係の宣言は、
	  この場合は、未設定のまま (設定しようとするとエラーが返りますので)

	<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>	  <!--
	  Thus <tt>Depends</tt> allows package maintainers to impose
	  an order in which packages should be configured.-->
	  このように、<tt>Depends</tt> フィールドによって、パッケージのメンテナはパッケージの設定順序を指定できます。

	      <p><!-- This declares an absolute dependency.-->

	      <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
		<tt>Depends</tt> フィールドは依存する側のパッケージが、

	      <p><!-- This declares a strong, but not absolute, dependency.-->

	      <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>


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

		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
		このフィールドは `Suggests' に似ていますが、逆向きに作用します。


		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
		このフィールドは <tt>Depends</tt> と似ていますが、この依存関係は目的のパッケージのインストール前に、先行依存 (predependency)
		するパッケージの完全インストールを <prgn>dpkg</prgn>

	      <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>		<!--
		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>Depends</tt> の場合と同じです。

	      <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.-->
		ただし、先行依存されているパッケージ (群) が、過去のある時点できちんと設定され、以後削除も部分的削除もされていない場合には、
	<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
	  <tt>Depends</tt> として並べ挙げるべきです。
	  そのほかの部分が必要とするパッケージは、その部品の相対的な重要性にしたがって Suggests なり、Recommends として参照されることになります。

      <sect id="conflicts"><heading><!-- Alternative binary packages -
	  <tt>Conflicts</tt> and <tt>Replaces</tt>-->
	  代替バイナリパッケージ - <tt>Conflicts</tt> と <tt>Replaces</tt>

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

	<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>	  <!--
	  A package will not cause a conflict merely because its
	  configuration files are still installed; it must be at least
	  競合関係にあるためには最低でも half-installed の状態でなければいけません。

	<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>	  <!--
	  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> フィールドは、ほとんど常にバージョン番号の指定に「より古い」という指定を含むべきではありません。

      <sect id="virtual"><heading><!-- Virtual packages - <tt>Provides</tt>-->
         仮想パッケージ - <tt>Provides</tt>

        <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>Suggests</tt>、<tt>Conflicts</tt>、<tt>Build-Conflicts</tt> 及び

	<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>	  <!--
	  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-->
	    Package: vm
	    Depends: emacs
	  <!-- and someone else releases an xemacs package they can say-->
	  というパッケージがあった場合、他の xemacs のパッケージが、
	    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>	  <!--
	  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>	  <!--
	  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
	  将来的には、<prgn>dpkg</prgn> に提供される仮想パッケージのバージョン番号を特定する機能が付加されることになるとは思います。

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

      <sect id="replaces"><heading><!-- <tt>Replaces</tt> - overwriting
	  files and replacing packages-->
	  <tt>Replaces</tt> - ファイルの上書きとパッケージの置換

	<p>	  <!--
	  The <tt>Replaces</tt> control file field has two purposes,
	  which come into play in different situations.-->
	  コントロールファイルの <tt>Replaces</tt> フィールドは、異なった状況下で作用する二つの目的を持っています。


	<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
	  <tt>Replaces</tt> フィールドでは仮想パッケージ (<ref id="virtual">)

	<sect1><heading><!-- Overwriting files in other packages-->

	  <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>&#45;&#45;force-overwrite</tt> flag is enabled by default,
	    downgrading the error to a warning,-->
	    <!-- しかし、現在のところ、dpkg のオプション
	    <tt>&#45;&#45;force-overwrite</tt> がデフォルトでオンになっており、
	    <!-- 訳注:前と不整合。ここは オフになるよう訳者権限で変更 -->

	  <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>	    <!--
	    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
	    <prgn>dpkg</prgn> はそのパッケージが持っているファイルが無く、
	    (削除の選択がされた) および「インストールされていない」
	    最終的な大掃除が必要であれば、そのパッケージの <prgn>postrm</prgn>
	    <ref id="mscriptsinstact"> をごらんください。

	  <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>	    <!--
	    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> フィールドがこのように使われるのは、

	<sect1><heading><!-- Replacing whole packages, forcing their

	  <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> 場合です。

      <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>-->
	  ソースパッケージとバイナリパッケージ間の関連 -

          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> 中のターゲットのうちで、
	    <tag><tt>Build-Depends</tt>, <tt>Build-Conflicts</tt></tag>
                <!-- 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> ターゲットに適用されます。
	    <tag><tt>Build-Depends-Indep</tt>, <tt>Build-Conflicts-Indep</tt></tag>
                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> ターゲットに適用されます。



    <chapt id="conffiles"><heading><!-- Configuration file handling-->

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

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

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

    <chapt id="sharedlibs"><heading><!-- Shared libraries-->共有ライブラリ

      <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>	<!--
	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 スクリプトから名前を変更したり、

      <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>postinst</prgn> で
	<prgn>ldconfig</prgn> が実行されるまでの間に <prgn>ld.so</prgn>
	これは、<prgn>dpkg</prgn> が (古いバージョンのライブラリを指すシンボリックリンクを上書きすることによって)
	ある種の (reiserfs のような)
	リリース <tt>1.7.0</tt> から、パッケージ作成時に <prgn>dpkg</prgn>

      <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,
	三番目に、開発版 (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>	<!--
	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> は共有ライブラリリンクがその一時的なファイルを指すようにしてしまうからです。

      <sect id="shlibs"><heading><!-- The <tt>shlibs</tt> File Format-->
        <tt>shlibs</tt> ファイルの書式

	<p>	  <!--
	  This file is for use by <prgn>dpkg-shlibdeps</prgn> and is
	  required when your package provides shared libraries.-->
	  このファイルは、<prgn>dpkg-shlibdeps</prgn> によって使用され、

	  <!-- Each line is of the form:-->それぞれの行はつぎのものから構成されます。
	    <var>library-name</var> <var>version-or-soname</var> <var>dependencies ...</var>

	<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>	  <!--
	  <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>	  <!--
	  <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>	  <!--
	  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>shlibs</var>
	    libfoo 1	foo (>= 1.2.3-1)

	<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> が出力する警告を回避するのに役立ちます。

      <sect><heading><!-- Further Technical information on

	<sect1><heading><!-- <em>What</em> are the <tt>shlibs</tt> files?-->
	  <tt>shlibs</tt> とは <em>何か</em>

	  <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>	    <!--
	    Other <tt>shlibs</tt> files that exist on a Debian system are-->
	    Debian システム上にある他の <tt>shlibs</tt> ファイルを次に列挙します。
	      <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>
	    <!-- These files are used by <prgn>dpkg-shlibdeps</prgn> when
	    creating a binary package.-->
	    <prgn>dpkg-shlibdeps</prgn> はバイナリパッケージのビルド時これらのファイルを使います。</p>

	<sect1><heading><!-- <em>How</em> does <prgn>dpkg-shlibdeps</prgn>
	    <prgn>dpkg-shlibdeps</prgn> は <em>どのように</em> 動作するのか?
	    <!-- determines the shared libraries directly-->
	      <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> を呼ぶようになっています。
		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> を使うと、直接使われているライブラリと間接的に使われているライブラリのすべてが列挙されます。

		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
		<prgn>dpkg-shlibdeps</prgn> を実行する必要があります。
		<!-- 時制が転んでいる。objdump を使うように変更済みのため、こうしなければならない、であって、今後こうする、ではないはず。-->
		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>
		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>
	    <!-- used by the compiled binaries and libraries passed through
	    on its command line.-->

	    <!-- For each shared library linked to,
	    <prgn>dpkg-shlibdeps</prgn> needs to know-->
	    <list compact="compact">
	      <item><p>the package containing the library, and</p></item>
	      <item><p>the library version number,</p></item>

	    <!-- and it scans the following files in this order:-->
	    <enumlist compact="compact">

	<sect1><heading><!-- <em>Who</em> maintains the various
	    <tt>shlibs</tt> files-->
	    様々な <tt>shlibs</tt> ファイルを <em>誰が</em> 管理しているのか?

	    <list compact="compact">
		<p><!-- <tt>/etc/dpkg/shlibs.default</tt> - the maintainer
		  of dpkg-->
		  <tt>/etc/dpkg/shlibs.default</tt> - dpkg のメンテナ </p>
		  <!-- - the maintainer of each package-->
		  - それぞれのパッケージのメンテナ</p>
		  <!-- <tt>/etc/dpkg/shlibs.override</tt> - the local
		  system administrator-->
		  <tt>/etc/dpkg/shlibs.override</tt> - ローカルのシステム管理者
		<p><!-- <tt>debian/shlibs.local</tt> - the maintainer of
		  the package-->
		  <tt>debian/shlibs.local</tt> - そのパッケージのメンテナ
	    <!-- 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> ファイルを持つようになるまで、既定値を決めるために置かれています。

	<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> 使うか ?

	  <sect2><heading><!-- If your package doesn't provide a shared

	    <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>
	      (つまり、スクリプトを含まない) の場合、次を使用してください。
		dpkg-shlibdeps debian/tmp/usr/bin/* debian/tmp/usr/sbin/*
	      <!-- 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.-->
	      <tt>debian/shlibs.local</tt> を作成する必要があるでしょう。</p>

	  <sect2><heading><!--If your package provides a shared library-->

	    <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>
		install -m644 debian/shlibs debian/tmp/DEBIAN
	      <!-- If your package contains additional binaries see above.-->

	<sect1><heading><!-- <em>How</em> to write-->
	    <tt>debian/shlibs.local</tt> を <em>どのように</em> 書くのか

	  <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.-->
	    <em>一時的</em> 解決のためのものです。

	  <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> をパッケージ作成中だとします。
	      $ 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)
	    <!-- And when you ran <prgn>dpkg-shlibdeps</prgn>-->
	    <prgn>dpkg-shlibdeps</prgn> を実行すると、次のようになっている場合
	      $ 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)
	    <!-- 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
	    <prgn>foo</prgn> バイナリは、
	    <prgn>libbar</prgn> 共有ライブラリに依存していますが、
	    <tt>/var/lib/dpkg/info/</tt> に <tt>*.shlibs</tt>

	      $ 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
	    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> 中に含めてください。
	      libbar 1 bar1 (>= 1.0-1)
	    <!-- 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> ファイルを削除することができます。

      <!-- <heading>The Operating System</heading> -->

	  <!--	<heading>File system hierarchy</heading> -->

	  <!-- <heading>Linux File system Structure</heading> -->
	  <heading>Linux ファイルシステム構造</heading>
	    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
	    インストールされるファイルやディレクトリの配置はすべて Linux
	    File system Hierarchy Standard (FHS) に従わなければなりません。
	    <url id="http://www.pathname.com/fhs/";> にもあります。
	    下記の標準に対する質問は <prgn>debian-devel</prgn> に送るか、
	    もしくは FHS の責任者である Daniel Quinlan
	    <email>quinlan@xxxxxxxxxxxx</email> に問い合わせて下さい。
	  <!-- <heading>Site-specific programs</heading> -->

	    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>
	    <!-- 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> 以下のディレクトリ中に作ることはかまいません。
	    (それが空であれば) 同時に削除される様になっていなければいけません。


	    <!-- 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> ディレクトリ直下には FHS のセクション 4.5
	     4.5 に列挙されているディレクトリは消してはいけません。
	    <!-- 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> 配下のディレクトリが含められていても、
	    For example, the <prgn>emacs</prgn> package will contain
	      mkdir -p /usr/local/lib/emacs/site-lisp || true
	    in the <tt>postinst</tt> script, and
	      rmdir /usr/local/lib/emacs/site-lisp || true
	      rmdir /usr/local/lib/emacs || true
	    in the <tt>prerm</tt> script.

mkdir -p /usr/local/lib/emacs/site-lisp || true
rmdir /usr/local/lib/emacs/site-lisp && \
rmdir /usr/local/lib/emacs || \

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

	    <!-- 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'

	    <!-- 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>.  -->
	    2775 (group 書き込み許可、group id セット) を、そしてオーナーとしては <tt>root.staff</tt> を設定しておくべきです。

	  <!--<heading>The system-wide mail directory</heading>-->
	    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> (&gt;= 2.1.3-13), or on
	    <package>base-files</package> (&gt;= 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>
	    を用いるパッケージは <package>libc6</package> (&gt;= 2.1.3-13)
	    か <package>base-files</package> (&gt;= 2.2.0)

      <sect id="users_and_groups">
	<!-- <heading>Users and groups</heading> -->

	  <!-- The Debian system can be configured to use either plain or
	  shadow passwords.-->
	  Debian システムは平文パスワードとシャドウパスワードのいずれの設定とすることも可能です。

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

	  <!-- Apart from this we should have dynamically allocated ids,
	  which should by default be arranged in some sensible
	  order &#45;&#45; but the behavior should be configurable.-->
	  これとは別に動的に割り当てられる ID があります。このような ID

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

	  <!-- The UID and GID ranges are as follows: -->
	  UID と GID の割り当てを下記に示します。
		<!-- 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
		Debian プロジェクトで共通に割り当てられ、すべての Debian
		システムで同じ目的のために使われるものです。これらの ID
		はすべての Debian システムの <tt>passwd</tt> と
		<tt>group</tt> に現れ、<tt>base-passwd</tt>
		更新の際にこの範囲にある ID は自動的に追加されます。</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
		静的に割り当てられた uid や gid が必要なパッケージはこの範囲の
		ID を使わなければなりません。当該パッケージのメンテナは
		ID を <tt>base-passwd</tt> のメンテナに割り当ててもらう必要があります。

		<!-- 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 &#45;&#45;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> を使ってこの範囲のユーザやグループを作成してください。
		 <tt>adduser.conf</tt> の範囲指定で使わない ID を選択してください。

		<!-- 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
		<prgn>adduser</prgn> はこの範囲の UID と GID
		を割り当てますが、この動作は <tt>adduser.conf</tt>

	      <!-- <p>Reserved.</p></item> -->

		<!-- 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 プロジェクトとして共通に割り当てているものですが、

		<!-- 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
		これらの ID はあまり使われないパッケージや、多くの静的に割り当てられた
		ID を必要とするパッケージのためのものです。
		このようなパッケージでは <tt>/etc/passwd</tt> や
		<tt>/etc/group</tt> を調べて、(<prgn>adduser</prgn>
		引き続いて ID を要求していく可能性のあるようなパッケージでは、割り当てた
		ID の後に将来の追加のために保留部を残しておかなければいけません。

	      <!-- <p>Reserved.</p></item> -->

	      <!-- <p>User `<tt>nobody</tt>.'</p></item> -->
	      <p>ユーザ `<tt>nobody</tt>' に割り当てられています。このユーザ
	      id はグループ `<tt>nogroup</tt>' に割り当ててください。</p></item>

		<!-- <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>. この値はエラー検出判定に用いるため、使わないでください。

      <sect id="sysvinit">
	<!-- <heading>System run levels</heading> -->

	<sect1 id="/etc/init.d">
	  <!-- <heading>Introduction</heading> -->

	    <!-- 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"
	    <tt>/etc/init.d</tt> ディレクトリにはブート時と init の状態
	    (ランレベル) が変わったときに (<manref name="init" section="8">
	    参照)、<prgn>init</prgn> に実行されるスクリプトが納められてい
	    <!-- 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> パッケージで実装されている、もう一つの方法による実装の詳細については、当該パッケージのドキュメントを参照して下さい。

            <!-- 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>
	    <tt>/etc/rc<var>n</var>.d</tt> ディレクトリ内を見て、
	    実行すべきスクリプトを探します。ここで <var>n</var>
	    また `S' はブート時のスクリプトを指します。

	    <!-- 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>
	    はスクリプトの名前を示しています (この名前は

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

	    <!-- 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>stop</tt>
	    <tt>S</tt> で始まるリンク先を <tt>start</tt> オプション付きで実行します。

	    <!-- 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> を起動するものよりも小さい番号にします。

	  <!-- <heading>Writing the scripts</heading> -->

	    <!-- 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> にスクリプトを置くべきです。
		  <!-- start the service, -->

		  <!-- stop the service, -->

		  <!-- stop and restart the service,-->

		  <!-- cause the configuration of the service to be
		  reloaded without actually stopping and restarting
		  the service, -->

		  <!-- cause the configuration to be reloaded if the
		  service supports this, otherwise restart the
		  service. -->

	    <!-- 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>force-reload</tt> の各オプションは
	    <tt>/etc/init.d</tt> 内の全てのスクリプトがサポートしていなければなりませんが、
	    <tt>reload</tt> オプションのサポートは任意です。

	    <!-- 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> を用いるようにすることです。

	    <!-- 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> オプションは、

	    <!-- 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> 文をスクリプトの先頭におくべきです。

test -f <var>program-executed-later-in-script</var> || exit 0
	    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>' スクリプトを実行する際に参照されます。

	    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>' スクリプトはそれが消されていた場合にも失敗することなく妥当に振る舞わなければいけません。

	  <!-- <heading>Managing the links</heading> -->
	    <!-- 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> スクリプトの中で使います。

	    <!-- 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> に変更を加えるときには必ず

	    <!-- 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) にて、各種サービスを開始させ、
	    システムの管理者は <prgn>update-rc.d </prgn> を実行して、
	    シンボリックリンクによる管理がなされている場合には <tt>/etc/rc<var>n</var>.d</tt>
	    <tt>/etc/runlevel.conf</tt> を変更することによって、ランレベルをカスタマイズすることができます。

	    <!-- To get the default behavior for your package, put in
	    your <tt>postinst</tt> script -->
	    <tt>postinst</tt> スクリプトに次のように書きます。
update-rc.d <var>package</var> defaults &gt;/dev/null
	    <!-- and in your <tt>postrm</tt> -->
	    <tt>postrm</tt> では次のようになります。
if [ purge = "$1" ]; then
	update-rc.d <var>package</var> remove &gt;/dev/null

	    <!-- 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> にポストしましょう。

	    <!-- 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"> を見て下さい。

	  <!-- <heading>Boot-time initialization</heading> -->
	  <heading> ブート時における初期化 </heading>

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

	    <!-- <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> を使わなければいけません。

	    <!-- <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 リストに含めることは
	    conffile としてマークするか、メンテナスクリプト (<ref id=
	    "config files">参照) の中で適切に扱うようにしてください

	  <!-- <heading>Example</heading> -->

	    <!-- 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
	    <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 プログラムへパラメータを渡すために使うことができる設定可能な値を含むファイルを一つ持っています。

# Original version by Robert Leslie
# &lt;rob@xxxxxxxx&gt;, edited by iwj and cs

test -x /usr/sbin/named || exit 0

# Source defaults file.
if [ -f /etc/default/bind ]; then
	. /etc/default/bind

case "$1" in
	      echo -n "Starting domain name service: named"
	      start-stop-daemon --start --quiet --exec /usr/sbin/named \
	                        -- $PARAMS
	      echo "."

	      echo -n "Stopping domain name service: named"
	      start-stop-daemon --stop --quiet  \
	      --pidfile /var/run/named.pid --exec /usr/sbin/named
	      echo "."

	      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 "."

	      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

exit 0

	    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>'
# Specified parameters to pass to named. See named(8).
# You may uncomment the following line, and edit to taste.
#PARAMS="-u nobody"
	    <!-- Another example on which to base your
	    <tt>/etc/init.d</tt> scripts is in
	    <tt>/etc/init.d/skeleton</tt>. -->

	    <!-- 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> には次のように書けば良いことになります。
update-rc.d bind defaults >/dev/null
	    <!-- And in its <tt>postrm</tt>, to remove the links when
	    the package is purged: -->
if [ purge = "$1" ]; then
	update-rc.d bind remove >/dev/null
	<!--<heading>Cron jobs</heading>-->
	<heading>Cron ジョブ</heading>

	  Packages must not modify the configuration file
	  <tt>/etc/crontab</tt>, and they must not modify the files in
	  パッケージは <tt>/etc/crontab</tt> 設定ファイルを変更してはいけません。
	  また、<tt>/var/spool/cron/crontabs</tt> 内のファイルを変更してもいけません。

	  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 -->
	  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
	  毎日(daily)、毎週(weekly)、毎月(monthly) 実行されます。
	  正確な時刻は <tt>/etc/crontab</tt> に記載されています。</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">参照)

	  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
	  パッケージは <tt>/etc/cron.d/<var>package-name</var></tt>
	  <tt>/etc/crontab</tt> と同じ書式で、<prgn>cron</prgn>
	   (注記:この <tt>/etc/cron.d</tt> の中のエントリは
	  <prgn>anacron</prgn> では処理されないので、ここにおくジョブはシステムが停止しているときには行う必要がないものに限られます。)
	  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.-->
	  そうしないと、パッケージをパージ (完全削除) ではなく単に削除したときには設定ファイルがシステムに残ったままになっているので、問題が起きてしまいます。

	<!-- <heading>Console messages</heading>-->

	  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 の起動とシャットダウン時の見栄えをより一貫したものとすることです。

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

	  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

		<!--Every message should cover one line, start with a
		capital letter and end with a period `.'.-->
		`.' で終わらなければなりません</p></item>

		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.-->
		`...' を使います。
		作業が終了したら `done' と表示して改行してください。
		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-->
		メッセージを作成してください。礼儀正しく :-)
I'm starting network daemons: nfsd mountd.
		<!-- just say --> と表現したいならば、単に次のようにしてください。
Starting network daemons: nfsd mountd.

	  <!-- The following formats should be used</p> -->
	      <p><!-- when daemons get started.-->デーモンを開始するとき</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行にし、
Starting &lt;description&gt;: &lt;daemon-1&gt;&lt;daemon-2&gt; &lt;...&gt; &lt;daemon-n&gt;.
		<!-- The &lt;description&gt; should describe the subsystem
		the daemon or set of daemons are part of, while
		&lt;daemon-1&gt; up to &lt;daemon-n&gt; denote each
		daemon's name (typically the file name of the
		&lt;description&gt; は対象となる一つまたは複数のデーモンの属するサブシステムについて記述してください。
		から始まって &lt;daemon-n&gt; までは各デーモンの名前 (通常はそのプログラムのファイル名) を記載してください。

		For example, the output of /etc/init.d/lpd would look like:-->
		例えば <tt>/etc/init.d/lpd</tt> の出力は次のようになります:
Starting printer spooler: lpd.

		<!-- This can be achieved by saying -->
echo -n "Starting printer spooler: lpd"
start-stop-daemon --start --quiet lpd
echo "."
		<!-- in the script. If you have more than one daemon to
		start, you should do the following:-->
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 "."
		<!--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>when something needs to be configured.</p>-->

		If you have to set up different parameters of the
		system upon boot up, you should use this format:-->
Setting &lt;parameter&gt; to `&lt;value&gt;'.

		You can use the following echo statement to get the
		quotes right: -->
		引用符が正しくなるようにするには、次の echo 文を使ってください:
echo "Setting DNS domainname to \`"value"'."

		Note that the left quotation mark (`) is different
		from the right (').-->
		左引用符 (`) と右引用符 (') が違うことに気を付けてください。

	      <!-- <p>when a daemon is stopped.</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>

		<!-- So stopping the printer daemon will like like this:-->
Stopping printer spooler: lpd.

	      <!-- <p>when something is executed.</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' でシステムの時計を合わせたり、
Doing something very useful...done.
		<!-- 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.' を表示し、ユーザに何故待たされていたのかを知らせなければいけません。

echo -n "Doing something very useful..."
echo "done."
		<!-- in your script.--></p></item>

	      <!-- <p>when the configuration is reloaded.</p>-->

		When a daemon is forced to reload its configuration
		files you should use the following format:-->
Reloading &lt;daemon's-name&gt; configuration...done.

	      <!-- <p>when none of the above rules apply.</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.-->

	<heading><!-- Menus-->メニュー</heading>

          Menu entries should follow the current menu policy as
          defined in the file <ftpsite>ftp.debian.org</ftpsite> in
          or your local mirror. In addition, it is included in the
	  <tt>debian-policy</tt> package.-->
	  Menu エントリは現在の Menu ポリシーに従う必要があります。この
	  Menu ポリシーは <ftpsite>ftp.debian.org</ftpsite> の
	  または手近のミラーサイトに置かれています。また、この Menu ポリシーは
	   <tt>debian-policy</tt> にも収録されています。

	  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
	  Debian の <tt>menu</tt> パッケージはアプリケーションや文書を提供するパッケージと
	  <em>メニュープログラム</em> (X window マネージャや
	   <prgn>pdmenu</prgn> のようなテキストベースのメニュープログラム)

	  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>

	  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
	  アプリケーションや web 文書を登録する方法の詳細については、
	  <tt>menu</tt> パッケージに付属する <em>Debian メニューシステム
	  </em> ドキュメントを参照してください。

	<!-- <heading>Multimedia handlers</heading>-->

	  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
	  or your local mirror. In addition, it is included in the
	  <tt>debian-policy</tt> package. -->
	  ある種の MIME タイプを表示/閲覧/再生/合成/編集や印刷する機能を
	  もつプログラムは <ftpsite>ftp.debian.org</ftpsite> の
	  または手近のミラーサイトの、現在の MIME サポートポリシーに従って登録を行う必要があります。
	  この MIME サポートポリシーは
	  <tt>debian-policy</tt> にも収録されています。

	  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 など)

	  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
	  MIME タイプを登録することで、メール受信ユーザプログラムやウェブブラウザがそれ自身で直接扱えない
	  MIME タイプの表示や編集などをハンドラを呼び出すことで行うことができるようになります。
	  <!-- view と display は違いが分からないのでカット -->

	<!-- <heading>Keyboard configuration</heading> -->

	  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 ディストリビューションのプログラムは下記のガイドラインに従わなければなりません。

	  Here is a list that contains certain keys and their interpretation:
	    <!-- <item><p>delete the character to the left of the

	    <!-- <item><p>delete the character to the right of the

	    <!-- <item><p>emacs: the help prefix</p></item>-->
	    <item><p>emacs では一連のヘルプを呼び出す</p></item>

	  <!-- 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 セッションなど)

	  <!-- The following list explains how the different programs
	  should be set up to achieve this:-->

	  <list compact="compact">
	    <!-- generates KB_Backspace in X.-->
	    X 環境ではバックスペースキーイベントを起こします</p></item>

	    <item><p>`<tt>Delete</tt>' <!-- generates KB_Delete in X.-->
	    X 環境では Delete キーイベントを起こします</p></item>

		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 設定とここでの解釈のリソースを一致させるためです。


		The Linux console is configured to make
		`<tt>&lt;&#45;&#45;</tt>' generate DEL, and `Delete' generate
		<tt>ESC [ 3 ~</tt> (this is the case at the
		Linux コンソールは `<tt>&lt;--</tt>' は DEL を、
		Delete キーは <tt>ESC [ 3 ~</tt> を生成するように設定されています

		X applications are configured so that Backspace
		deletes left, and Delete deletes right.  Motif
		applications already work like this.-->
		X アプリケーションはバックスペースキーはカーソルの左を、
		Delete キーは右を消すように設定します。Motif アプリケーションは既にこうなっています。

	    <item><p><!-- stty erase <tt>^?</tt> .-->
	        stty erase は <tt>^?</tt> と設定します</p></item>

		The `xterm' terminfo entry should have <tt>ESC [ 3
		~</tt> for kdch1, just like TERM=linux and
		`xterm' の terminfo エントリは kdch1 に
		<tt>ESC [ 3 ~</tt> を設定します。TERM=linux と TERM=vt220

		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>

		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>

	  <!--This will solve the problem except for:-->

	  <list compact="compact">
		Some terminals have a <tt>&lt;&#45;&#45;</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
		一部のターミナルでは <tt>&lt;--</tt> キーで <tt>^H</tt>
		Emacs のヘルプを <tt>^H</tt> で呼ぶことができません
		 (Emacs では `stty erase' の設定の方が優先され、かつ正しく設定されているという仮定の下です)。
		M-x help または F1 (あれば) を代わりに使うことができます。

		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 を手動設定して正しく動くようにしてください。

		Some systems (including previous Debian versions) use
		xmodmap to arrange for both <tt>&lt;&#45;&#45;</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>&lt;&#45;&#45;</tt>
		一部のシステム (以前の Debian の版もそうでした) では
		<tt>&lt;--</tt> と Delete キーが Delete キーイベントを起こすよう
		 xmodmap で設定しています。私たちは、 クライアントに対して同一の X リソースで私たちの望む設定を行い、
		を使ったシステムでは Delete はたぶん動きませんが、
		<tt>&lt;--</tt> の方は正しく動作します。</p></item>

		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>&lt;&#45;&#45;</tt> will.-->
		一部の OS では xterm などの端末設定の terminfo 中の kdch1
		このポリシーに従ったシステムからログインした場合には Delete
		キーは正常動作しませんが、<tt>&lt;--</tt> は正しく動作します。

	<!-- <heading>Environment variables</heading>-->

	  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 のような設定ファイルで設定しなければなりませんが、このような設定ファイルがすべてのシェルでサポートされているわけではないためです。

	  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

	  Here is an example of a wrapper script for this purpose:-->

export BAR
exec /usr/lib/foo/foo "$@"

	  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
	  更に <tt>/etc/profile</tt> は <prgn>base-files</prgn>
	<!-- <heading>Files</heading> -->

	  <!-- <heading>Binaries</heading> -->

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

	    <!-- Generally the following compilation parameters should be used: -->
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 をかけてください)

	    <!-- 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
	    バイナリファイルは既定値として strip をかけておくべきであることに留意してください。
	    これは <prgn>install</prgn> の
	    <tt>-s</tt> フラグか、パッケージツリーを作成する前にいったんプログラムを
	     <tt>debian/tmp</tt> に移して <prgn>strip</prgn>

	    <!-- 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
	  <!-- 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 の断片はこの両方の条件を試す例の部分だけを示したものです
	      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><!-- Now this has several added benefits:-->
		    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 を編集する必要は最早無い)
		    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 もしない)
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
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
	  <!-- 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 で従うべき内容を示したものではないことに注意してください。
	    <!-- 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&#45;&#45;they are often inappropriate for our
	    ある種のバイナリ (たとえば計算量の多いプログラム) にはそれなりのフラグ (<tt>-O3</tt> など)
	  <!-- <heading>Libraries</heading> -->

	    <!-- 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> は二度コンパイルされる必要があることになります。

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

	    <!-- Note that all installed shared libraries should be
	    stripped with -->
	    インストールされる共有ライブラリは次のようにして strip されているべきです。
strip --strip-unneeded &lt;your-lib&gt;
	    <!-- (The option `&#45;&#45;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

	    <!-- 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 しない共有ライブラリを作成したほうがいい場合もあることに気をつけてください。


	  <!-- 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 関係、わかってないんであやしい -->
	  <!-- 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 ファイル中に保存するようになっています。
	  <!-- 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
	  というわけで、共有ライブラリを libtool を使って作成するパッケージでは、
	  <em>-dev</em> パッケージに <em>.la</em> ファイルを含めるべきです。
	  ただし、libtool の <em>libltdl</em>
	  ライブラリに依存するパッケージは例外で、この場合には .la

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


	  <!-- <heading>Shared libraries</heading> -->

	    <!-- Packages involving shared libraries should be split up
	    into several binary packages.-->

	    <!-- For a straightforward library which has a development
	    environment and a runtime kit including just shared
	    libraries you need to create two packages:
	    (<var>soname</var> is the shared object name of the shared
	    library&#45;&#45;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> です。
	    (.so ファイル名 (<var>soname</var>) は共有ライブラリの共有オブジェクト名です。

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

	    <!-- 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>) を変更して

	    <!-- 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>&#45;&#45;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>) がパッケージ名にないことに注意)

	    <!-- 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>) の変更は、このライブラリ集合の各ライブラリに対して一括して実施するようにしてください。


	    <!-- 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 パッケージングツールのその他の説明文書)
	    <!-- 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
	    <prgn>ld.so</prgn> はこのような属性を必要としていませんし、


	<sect id="scripts">
	  <!-- <heading>Scripts</heading>-->

	    <!-- 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> 行を追加して指定しなければいけません。


	    <!-- In the case of Perl scripts this should be
	    それが perl スクリプトの場合は、その行は
	    <tt>#!/usr/bin/perl</tt> でなければいけません。

	    <!-- 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>
	    シェルスクリプト (<prgn>sh</prgn> や <prgn>bash</prgn> を使う)
	     では、特殊な場合をのぞいて最初に <tt>set -e</tt> を書いてエラーを検出するようにすべきです。
	    <tt>set -e</tt> を使うか、<em>全</em>コマンドの終了ステータスを明示的に調べてエラーを検出すべきです。

	    <!-- 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 互換なシェルのどれかへのシンボリックリンクです
	      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 ではどちらにせよ必須となるとのことですので。

	    <!--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
	    従って、`<tt>/bin/sh</tt>' をインタープリタに指定したシェルでは
	     POSIX 規定の機能だけを使うべきです。スクリプトで POSIX
	    適切なシェルを最初に指定 (例えば `<tt>#!/bin/bash</tt>' のように)
	     (そのシェルパッケージが `Essential' 扱いになっている、
	    例えば <prgn>bash</prgn> のような場合は依存関係の指定は不要です)。


	    <!-- 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
	    スクリプトをできる限り POSIX 規定の機能だけを用いて書くようにし、
	    <tt>/bin/sh</tt> をインタープリタとして使えるようにしたいと思う場合、あなたのスクリプトが
	     <prgn>ash</prgn> で動くならおそらく POSIX 互換になっていると思います。
	    但し、疑問があるなら明示的に <tt>/bin/bash</tt> を使ってください。

	    <!-- 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>system</tt> などが含まれます。</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>
	  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> の
	    訳注:日本語訳はとりあえず <ftpsite>ftp.sra.or.jp</ftpsite> の
	    <!-- ほかにもあるとは思うけど、すぐには見つからなかった。--></p>
	  上流のパッケージに <prgn>csh</prgn> スクリプトが含まれているときには、
	  そのスクリプトが <tt>#!/bin/csh</tt> で始まり、そのパッケージを
	   <prgn>c-shell</prgn> 仮想パッケージに依存するよう設定したことをよく確認してください。


	    <!-- 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> に)

	    <!-- 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> ユーティリティはこの目的でスクリプト中で使うためのものです。

	  <!-- <heading>Symbolic links</heading> -->

	    <!-- 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 `/'.)-->
	    通常、トップレベルディレクトリ (ルートディレクトリ `/'
	    にあるディレクトリがトップレベルディレクトリです) 内のシンボリックリンクは相対参照とします。

	    <!-- In addition, symbolic links should be specified as short
	    as possible, i.e., link targets like `foo/../bar' are
	    例えば `foo/../bar' のような参照はよろしくありません。</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> の最初の引数に現れるよう文字列を与えるだけです。
	    <!-- For example, in your <prgn>Makefile</prgn> or
	    <tt>debian/rules</tt>, do things like: -->
	    例えば、<prgn>Makefile</prgn> や <tt>debian/rules</tt> で次のような処理を行ってください。

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

	    <!-- 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
	    <tt>.gz</tt>' で終わる、`bar.gz' のような名前にしてください)。

	  <!-- <heading>Device files</heading> -->

	    <!-- Package must not include device files in the package file

	    <!-- 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> を呼び出してください。

	    <!-- 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> などのスクリプト中でデバイスファイルを削除してはいけません。そのような処置は管理者に任せてください。

	    <!-- Debian uses the serial devices
	    <tt>/dev/ttyS*</tt>. Programs using the old
	    <tt>/dev/cu*</tt> devices should be changed to use
	    Debian ではシリアルデバイスファイル名に <tt>/dev/ttyS*</tt>
	    を使います。昔の <tt>/dev/cu*</tt> を使っているプログラムは
	    <tt>/dev/ttyS*</tt> に変更すべきです。</p>

      <sect id="config files">
	  <!-- <heading>Configuration files</heading> -->
	  <!-- <heading>Definitions</heading>-->
	      <!-- <tag>configuration file</tag> -->
		  <!-- 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.-->
		  <!-- 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>参照)
	    <!-- 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>
	    <!-- 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>
	    など) は事実上の設定ファイルですし、そのように扱われます。</p>
	  <!-- <heading>Location</heading> -->
	    <!-- 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>
	    <!-- 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
	    あなたのパッケージが <tt>/etc</tt> 以外の場所に設定ファイルを作成し、
	    かつそのパッケージが <tt>/etc</tt> を使うように修正するのが望ましくない場合でも、設定ファイル自体は
	  <!-- <heading>Behavior</heading> -->
	    <!-- Configuration file handling must conform to the following
	    behavior: -->
		<!-- <p>local changes must be preserved during a package
		  upgrade</p> -->
		<!-- <p>configuration files must be preserved when the
		  package is removed, and only deleted when the
		  package is purged.</p> -->
		 (purge) の際にのみ削除するようにしなければいけません。

	    <!-- 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
	    この挙動を行わせるやさしい方法は設定ファイルを <tt>conffile
	    </tt> にしてしまうことです。これはほとんどのインストールの場合にそのままで使え、
	    更に、この方法を使うためには標準設定のファイルがパッケージの配布物に含まれていること、またインストール中 (やその他の際に)
	    In order to ensure that local changes are preserved
	    correctly, no package may contain or make hard links to
	    パッケージの conffile にハードリンクを張ることは、ローカルで加えた変更を正しく残せなくなるため、許されていません

		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.-->
		原則の解説: ハードリンクには二つの問題があります。まず第一にそのうちの一つのファイルを編集する際にリンクを切ってしまうエディタがあり、
		が <tt>conffile</tt> のアップグレード時にリンクを切ってしまうかもしれません。

	    <!-- 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> がメンテナスクリプトを呼び出す様々なやり方に対応できねばならず、ユーザの設定ファイルを前もって問い合わせることなしに上書きしたり壊したりしてはいけません。

	    <!-- 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>
		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/&lt;package&gt;</tt> or
		<tt>/usr/lib/&lt;package&gt;</tt> with a symbolic link
		from <tt>/usr/share/doc/&lt;package&gt;/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/lib/&lt;package&gt;</tt> に置き、
	    それが例なら <tt>/usr/share/doc/&lt;package&gt;/examples</tt>
	    <prgn>dpkg</prgn> で処理するファイルにして (すなわち、
	    <tt>conffile</tt> では<em>無いようにする</em>) ください。
	    <!-- 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> がパッケージをアップグレードする際に毎回ファイルを上書きするかどうか問い合わせてくるようになり、頭を掻きむしることになります。
	  <!-- <heading>Sharing configuration files</heading>-->
	    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> していると指定しなければいけません。
	    <!-- The maintainer scripts should not alter the conffile of
	    <em>any</em> package, including the one the scripts belong
	    <em>いかなる</em>パッケージの conffile を変更してもいけません。</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> と定義してください。その設定ファイルを
	     (depend) する必要があります。
	    <!-- 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> これらのパッケージが設定ファイルを変更する場合がある、という状況下では、以降の各項を満たすようにしてください。
		  <!-- have one of the related packages (the "core"
		  package) manage the configuration file with
		  maintainer scripts as described in the previous
		  関連したパッケージの一つ ("core" パッケージと呼びます)
		  <!-- the core package should also provide a program that
		  the other packages may use to modify the
		  configuration file.-->
		  "core" パッケージは他のパッケージが設定ファイルを変更する際に用いるプログラムを提供しなければいけません。
		  <!-- 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"
	    <!-- 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> パッケージを参考にしてください)。
	  <!-- <heading>User configuration files ("dotfiles")</heading> -->
	  <heading>ユーザ設定ファイル (ドットファイル)</heading>
	    <!-- 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> 以下は他のどのプログラムからも参照しては
	    <!-- 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 に列挙しておくべきです)。
	    <!-- 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 の標準インストール状態でそこそこ真っ当に動くように設定されているべきです。
	    <!-- 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
	    したがって、 Debian パッケージのプログラムを真っ当に動くようにする設定が必要なら、
	    <tt>/etc</tt> 内にサイト共通で利用する設定ファイルを用意してください。
	    <!-- <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> はできる限り空になるようにしましょう。


	<!-- <heading>Log files</heading> -->
	  <!-- 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
	  <!-- 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>) の両方を備えています。
	<!-- 訳者権限で tag 追加 -->
	  <!-- 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>.log</tt>
	  という名にします。たくさんの log ファイルを持つ場合や、
	   (<tt>/var/log</tt> は <tt>root</tt> ユーザからのみ書き込めます)
	   特に理由がなければ <tt>/var/log/<var>package</var></tt>

	  <!-- 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"> を見てください)。
/var/log/foo/* {
	rotate 12
		/etc/init.d/foo force-reload
	  <!-- 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 シグナルを送信するものです。

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

	  <!-- <heading>Permissions and owners</heading> -->

	    <!-- 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> で相談するのがいいでしょう。

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

	    <!-- Directories should be mode 755 or (for group-writability)
	    mode 2775.  The ownership of the directory should be
	    consistent with its mode&#45;&#45;if a directory is mode 2775, it
	    should be owned by the group that needs write access to
	    ディレクトリのパーミッションは 755、あるいは、グループが書き込み可であれば
	     2775 にすべきです。ディレクトリの所有者は
	    つまりディレクトリのパーミッションが 2775 であれば、そこに書き込む必要のあるグループのユーザを所有者に設定してください。
	    <!-- 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&#45;&#45;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 していない実行ファイルに対して読み込み・実行許可を制限すべきではありません。
	    <!-- 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

	    <!-- 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.-->
	     setuid した実行ファイルはそのグループだけが実行できるような設定とすることを考えてください。
	    <!-- 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
	    <!-- 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 で行うほうが、可能ならばより良いやり方です。

	    <!-- 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
	    第二の方法は、プログラムが実行時にグループ名から uid、gid を決
	    定するもので、ID は動的に
	    割り当てられます。この場合、<prgn>debian-devel</prgn> で討議を行い、また base
	    システムの管理者にその名前が一意であること、静的に ID
	    これらの確認がすんだ後パッケージで pre- あるいは
	    postinst スクリプト等で (繰り返しますが後者が好ましいです)
	    必要に応じて <prgn>adduser</prgn>

	    <!-- 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 は静的か動的か良く考えて決めてください。
    <chapt id="customized-programs">
      <!-- <heading>Customized programs</heading> -->
      <sect id="arch-spec">
	<!-- <heading>Architecture specification strings</heading> -->

	  <!-- If a program needs to specify an <em>architecture specification
	    string</em> in some place, the following format has to be used: -->

	  <!-- where `&lt;arch&gt;' is one of the following: i386, alpha, arm,
	  m68k, powerpc, sparc and `&lt;os&gt;' is one of: linux, gnu.  Use
	  of <em>gnu</em> in this string is reserved for the GNU/Hurd
	  operating system.-->
	  ここで `&lt;arch&gt;' は i386、alpha、arm、m68k、powerpc、sparc
	  のいずれかです。また `&lt;os&gt;' は linux か gnu のどちらかになります。
	  ここでの <em>gnu</em> は GNU/Hurd オペレーティングシステムのために予約されています。

	  <!-- Note, that we don't want to use `&lt;arch&gt;-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
	  `&lt;arch&gt;-unknown-linux', since the `unknown' does not
	  look very good.-->
	  私たちは、他の Linux ディストリビューションとの互換性をなくすので、
	  `architecture-vendor-os' の場所に `&lt;arch&gt;-debian-linux'
	  を使わないようにしています。また、`unknown' は見苦しいので、
	  `&lt;arch&gt;-unknown-linux' も使いません。

	<!-- <heading>Daemons</heading>-->

	  <!-- 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/protocols</tt> と <tt>/etc/rpc</tt> は
	  <prgn>netbase</prgn> パッケージで管理されます。ほかのパッケージはこれらに修正を加えてはいけません。

	  <!-- 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>
	  メンテナは <prgn>netbase</prgn> パッケージのメンテナに連絡を取って、エントリを加えた新しい
	   <prgn>netbase</prgn> パッケージをリリースしてもらうべきです。

	  <!-- 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 モジュールを介さずにパッケージスクリプトから変更してはいけません。


	  <!-- 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> からは『ユーザによってコメントアウトされた行

        <!-- <heading>Using pseudo-ttys and modifying wtmp, utmp and lastlog</heading> -->
        <heading>仮想 tty の使用、wtmp、utmp、lastlog 等の更新</heading>

	  <!-- 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 してはいけません。

	  <!-- 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 してインストールしてください。


	<!-- <heading>Editors and pagers</heading> -->

	  <!-- 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
	  Debian ディストリビューションで利用できるエディタやページャにはたくさんの種類があるので、システム管理者とユーザが好みのエディタとページャを選択できるようにすべきです。

	  <!-- In addition, every program should choose a good default
	  editor/pager if none is selected by the user or system

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

	  <!-- 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
	  これら2つのプログラムは代替パッケージ機能 (alternatives) を通して管理されています。
	  `update-alternatives' スクリプトを使って自分を登録しておかなければいけません。


	  <!-- 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>,
	  EDITOR、PAGER 環境変数を参照して動作するようプログラムを修正するのが困難な場合は、
	  <tt>/usr/bin/sensible-editor</tt> と

	  これらは Debian 基本システムで提供されるスクリプトで、自動的に
	   <tt>/usr/bin/editor</tt> や
	  <tt>/usr/bin/pager</tt> を起動します。</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> でもこの処理が行われています。
	  <!-- 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' に依存する必要がなく
	      <!-- The Debian base system already provides an editor and
	      a pager program, -->
	      Debian ベースシステムが `editor' と `pager' プログラムを提供しています。

      <sect id="web-appl">
	<!-- <heading>Web servers and applications</heading> -->
	<heading>Web サーバとアプリケーション</heading>

	  <!-- This section describes the locations and URLs that should
	  be used by all web servers and web application in the Debian
	  この節では Debian システムでの全ての web サーバと web
	  アプリケーションから利用すべき場所 (ディレクトリ) といくつかの URL

	      <p><!-- Cgi-bin executable files are installed in the
		directory -->
		cgi-bin 実行ファイルは次のディレクトリにインストールしてください。

		<!-- and should referred to as -->

	    <!-- <item><p>Access to html documents</p> -->
	    <item><p>HTML 文書へのアクセス</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">

	    <!-- <item><p>Web Document Root</p> -->
	    <item><p>Web 文書ルートディレクトリ</p>

		<!-- Web Applications should try to avoid storing files in
		the Web Document Root.  Instead they should use the
		/usr/share/doc/&lt;package&gt; 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/&lt;package&gt;</tt> ディレクトリを使い、menu
		 パッケージ経由で web アプリケーションとして登録するべきです。
		どうしても Web 文書ルートディレクトリを使わざるをえない場合には、

		を 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 へ設定した場所へのシンボリックリンクでも良いでしょう。


      <sect id="mail-transport-agents">
	<!-- <heading>Mail transport, delivery and user agents</heading>-->

	  <!-- 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) のいずれであれ、下記の設定基準に準拠していることを確認してください。


	  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
	  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>
	  <!-- 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> を使って、次にドットファイルロックを使うか、二つのロックをブロックしないやり方

	      <!-- 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.-->
	  で使うべきです。<!--. Using the functions <tt>maillock</tt> and
	  <tt>mailunlock</tt> provided by the
	      <tt>liblockfile</tt> version &gt;&gt;1.01</p>
	  </footnote> packages is the recommended way to realize this. -->
	  <tt>liblockfile*</tt>パッケージ <footnote>
	      <tt>liblockfile</tt> version &gt;&gt;1.01</p>
	  に含まれる <tt>maillock</tt> と <tt>mailunlock</tt>

	  <!-- 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 グループから書き込み可能でなければなりません。

	  <!-- 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 されているべきです。

	  <tt>/etc/aliases</tt> <!-- is the source file for the system mail
	  aliases (e.g., postmaster, usenet, etc.)&#45;&#45;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> が見つからなくてもプログラムが落ちな

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

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

	  <!-- 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> の後に続く部分が書かれています (最後に改行が入ります)。

	  <!-- 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: -->
	  <tt>/etc/mailname</tt> に書くべき内容を問い合わせ、その内容を書いてください。
	  例えば、INN パッケージでは次のように質問しています。
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>']:
	  <!-- そのままに(一応)してあります。INN ってここ日本語にな
	  ってたんでしたっけ -->
	  <!-- where <var>syshostname</var> is the output of <tt>hostname
	  ここで <var>syshostname</var> は <tt>hostname --fqdn</tt>

	<!-- <heading>News system configuration</heading> -->

	  <!-- All the configuration files related to the NNTP (news)
	  servers and clients should be located under
	  NNTP (ニュース) サーバやクライアントに関係した設定ファイルはすべて
	   <tt>/etc/news</tt> 以下に置かなければなりません。</p>

	  <!-- There are some configuration issues that apply to a number
	  of news clients and server packages on the machine. These
	  are: -->

	    <item><p><!-- A string which should appear as the
		organization header for all messages posted
		by NNTP clients on the machine-->
		当該マシンの NNTP クライアントから投稿された記事の
		Organization ヘッダに現れる (べき) 文字列を格納します。

	    <item><p><!-- Contains the FQDN of the upstream NNTP
		server, or localhost if the local machine is
		an NNTP server.-->
		上流の NNTP サーバの FQDN が書かれています。
		自分自身がニュースサーバでもある場合には localhost

	  <!-- Other global files may be added as required for cross-package
	  news configuration.-->

	<!-- <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
	  <em>X ウィンドウシステム向けサポートを行うよう構成可能なプログラムは</em>
	   X ウィンドウシステムのサポートを含むように構成しなければいけません。
	  standard またはより高いプライオリティでインストールされるものである場合には、
	  X 関連のパッケージを別パッケージに分離してもかまいませんし、また
	  X をサポートした別バージョンのパッケージを作成してもかまいません。

         <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>、言い換えると直接または間接に実際の入力機器と表示ハードウェアを操作するパッケージはコントロールファイル中に仮想パッケージ


	      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
	  </footnote> 宣言すべきです。
	  <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
	  <tt>ncurses-base</tt> パッケージに terminfo
	  情報が記載されたターミナルタイプをサポートする X
	  ウィンドウシステムの <em>ターミナルエミュレータを提供するパッケージ</em>はコントロールファイル中に仮想パッケージ
	  20 で <tt>/usr/bin/x-terminal-emulator</tt> の代替とするよう宣言するべきです。

	  <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> の代替とするよう宣言するべきです。
	    <!-- <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
		ウィンドウマネージャが Debian メニューシステムをサポートしている場合、パッケージの既定設定でこのサポートが使えるようになっている

		設定ファイルを変更しなければならない場合、10 だけを足してください。
	    <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
		もしウィンドウマネージャが既定の設定下で <em>別の</em> ウィンドウマネージャを使って
		 X セッションを再起動可能 (X サーバを再起動せずに)
		なら 10 を足してください。そうでないなら何も足しません。
         <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 およびフォントサーバの変更なしにそれが有効になるように、また自分自身の情報を登録する際に他のフォントパッケージの情報を壊さないよういくつかの作業を行う必要があります。
		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>
		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
		BDF フォントは <tt>xbase-clients</tt> パッケージ収録の
		<tt>bdftopcf</tt> ユーティリティを使って PCF フォントに変換し、
		<tt>gzip</tt> を行い、解像度に応じたディレクトリに置くべきです。

		      100 dpi fonts should be placed in
		      100 dpi のフォントは
		      75 dpi fonts should be placed in
		      75 dpi のフォントは
		      Character-cell fonts, cursor fonts, and other
		      low-resolution fonts should be placed in
		Speedo fonts should be placed in
		Speedo フォントは
		<tt>/usr/X11R6/lib/X11/fonts/Speedo/</tt> に置くべきです。
		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
		Type 1 フォントは
		<tt>/usr/X11R6/lib/X11/fonts/Type1/</tt> に置くべきです。

		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>

		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
		フォントパッケージは上記の X
		この場合、実際にフォントを置く場所は FHS 準拠の場所にしてください。
		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" を付けた独立のバイナリパッケージを提供してください。

		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.-->
		 75dpi や 100dpi のフォントを収録していてはいけません。
		"-misc" を付けた独立のバイナリパッケージを提供してください。

		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>。

		      <tt>fonts.dir</tt> files must not be provided at
		      <tt>fonts.dir</tt> ファイルはどのような形でも収録してはいけません。

		      <tt>fonts.alias</tt> and <tt>fonts.scale</tt>
		      files, if needed, should be provided in the
		      <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
		      <tt>fonts.alias</tt> と <tt>fonts.scale</tt> ファイルは必要なら
		      <em>fontdir</em> は関連フォントが収録される
		       (つまり、<tt>75dpi</tt> や <tt>misc</tt> など)で、
		      <em>package</em> はそのフォントを収録したパッケージの名前です。
		      また、<em>extension</em> はファイルの内容に従い
		       <tt>scale</tt> か <tt>alias</tt>
		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
		Font packages that provide one or more
		<tt>fonts.scale</tt> files as described above must declare a
		versioned dependency on <tt>xbase-clients (&gt;=</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 (&gt;=</tt>
		<tt>mkfontdir</tt> を実行するまえに
		<tt>update-fonts-scale</tt> を実行しなければいけません。
		この実行処理はパッケージの post-installation と
		post-removal スクリプトで行われなければいけません。
		Font packages that provide one or more
		<tt>fonts.alias</tt> files as described above must
		declare a versioned dependency on <tt>xbase-clients
		(&gt;=</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>xbase-clients (&gt;=</tt>
		post-installation とpost-removal
		 <tt>update-fonts-alias</tt> を実行しなければいけません。
		Font packages must not provide alias names for the
		fonts they include which collide with alias names already in
		use by fonts already packaged.-->
		Font packages must not provide fonts with the same XLFD
		registry name as another font already packaged.-->
		フォントパッケージは既にパッケージ化されている他のフォントと同じ XLFD レジストリ名でフォントを収録してはいけません。
	<!-- ################################################ -->
	  <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
	  (&lt;&lt;</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>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 (&lt;&lt;</tt> へのコンフリクトを宣言してください。
	   <tt>/etc/X11/Xresources</tt> の中の
	  <em>ファイル</em> を壊す可能性があります。

	  <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 &#45;&#45; or install files into &#45;&#45;
	  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/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/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>
	  ではなく) に対してリンクを張るべきです。
	  <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

	<!--<heading>Perl programs and modules</heading>-->
	<heading>Perl プログラムとモジュール群</heading>
	  Perl programs and modules should follow the current Perl
          policy as defined in the file found on
	  <ftpsite>ftp.debian.org</ftpsite> in
	  or your local mirror.  In addition, it is included in the
	  <tt>debian-policy</tt> package.-->
	  Perl プログラムとモジュールは、現在の Perl ポリシーに従うべきです。
	  この Perl ポリシーは <ftpsite>ftp.debian.org</ftpsite> の
	  <tt>debian-policy</tt> パッケージにも収録されています。

	<!-- <heading>Emacs lisp programs</heading>-->
	<heading>Emacs lisp プログラム</heading>

	  <!-- 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> という名で収録されています) に当たってください。


	<!-- <heading>Games</heading>-->

	  <!-- The permissions on /var/games are 755
	  /var/games のパーミッションは 755 <tt>root.root</tt> です。

	  <!-- Each game decides on its own security policy.-->

	  <!-- 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
	  <tt>root.games</tt> にして 2755 で set-gid しておき、ファイルとディレクトリには適当なパーミッション
	  (例えば、770 <tt>root.games</tt>) を与えてもかまいません。
	  set-uid はセキュリティ上の問題が起きるのでしてはいけません
	  (アタックする人は set-uid
	  set-gid されたゲームでは、アタッカーはあまり重要ではないゲームのデータだけにアクセスできるようになるだけで、

	  <!-- 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 されたプログラムをたくさん作る必要がなくなることを意味しますし、引いてはセキュリティホールのリスクを減らすことにもなります。

	  <!-- 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
	  FHS で規定されているように、ゲームのバイナリは
	  <tt>/usr/games</tt> にインストールしてください。X ウィンドウシステムを使うゲームもここに入れてください。ゲームのマニュアル

	   (X 用、X 不使用の両方とも) は
	  <tt>/usr/share/man/man6</tt> にインストールしてください。</p>

    <!-- <chapt><heading>Documentation</heading> -->

	<!-- <heading>Manual pages</heading> -->
	<heading>マニュアル(man ページ)</heading>

	  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
	  マニュアルは <prgn>nroff</prgn> 形式で <tt>/usr/share/man</tt>
	  1 から 9 までのみをつかうべきです (詳しくは FHS 参照)。
	  フォーマット済みの 'cat' 形式のマニュアルをインストールしてはいけません。
	  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.-->


	  <!-- 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:
	    ln -s ../man7/undocumented.7.gz \
	  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>
ln -s ../man7/undocumented.7.gz \

	  <!-- 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&#45;&#45;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
	  <!-- Manual pages should be installed compressed using <tt>gzip
	  マニュアルは <tt>gzip -9</tt> で圧縮してインストールしなければいけません。

	  <!-- 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&#45;&#45;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> です) からの相対参照とすべきです。

	<!-- <heading>Info documents</heading> -->
	<heading>Info 形式の文書</heading>

	  <!-- 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> で圧縮しておいてください。

	  <!-- 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> を呼び出すべきです。

install-info --quiet --section Development Development \
	  <!-- It is a good idea to specify a section for the location of
	  your program; this is done with the <tt>&#45;&#45;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>&#45;&#45;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> を見て最もふさわしいものを選んでください。
	  (大文字小文字は区別しません) で、もう一つは最初の引数に一致するセクションがないときに作成する、新しいセクション名として使います。
	  <!-- You should remove the entries in the pre-removal script:-->
	  prerm スクリプト中では、次のようにしてエントリを削除するべきです。
install-info --quiet --remove /usr/share/info/foobar.info
	  <!-- 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">

	<!-- <heading>Additional documentation</heading> -->

	  <!-- 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> で圧縮しておいてください。

	  <!-- 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. -->
	  <!-- 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
	  バイナリパッケージ中の <tt>/usr/share/doc/<var>package</var></tt>
	  にソースパッケージに付いている各種のテキスト文書 (<tt>README</tt>
	  や changelog など) を入れるのは通常よい考えです。
	  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/&lt;package&gt;/</tt> and symlinked in
	  <tt>/usr/share/doc/&lt;package&gt;/</tt>. -->
	  システム管理者が <tt>/usr/share/doc</tt>
	  プログラムから参照されるが、同時に単独のドキュメントとしても役に立つようなファイルは <tt>/usr/share/&lt;package&gt;/</tt>

      <sect id="usrdoc">
      <!-- <heading>Accessing the documentation</heading> -->
         <!-- 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
         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
         以前の Debian リリースでは添付文書類は
         現在使われている <tt>/usr/share/doc/<var>package</var></tt>
         <tt>/usr/doc/<var>package</var></tt> から新しい文書の位置
         <tt>/usr/share/doc/<var>package</var></tt> へのシンボリックリンクを

         <prgn>dpkg</prgn> の問題のために単にパッケージにそのリンクを含めておくことはできません。
          <prgn>postinst</prgn> スクリプトに次の処理を含めておくことです。

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#
          <!-- And the following in the package's <prgn>prerm</prgn>: -->
          そして次の処理をパッケージの <prgn>prerm</prgn> に入れてください。
if [ \( "$1" = "upgrade" -o "$1" = "remove" \) \
       -a -L /usr/doc/#PACKAGE# ]; then
        rm -f /usr/doc/#PACKAGE#

	<!-- <heading>Preferred documentation formats</heading>-->

	  <!-- The unification of Debian documentation is being carried out
	  via HTML.-->
	  Debian プロジェクトでは 文書の形式の統一化は HTML を通して行なわれています。

	  <!-- 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
	  パッケージに各種書式に変換可能なマークアップ形式の詳細文書が付属している場合は、バイナリパッケージには可能なかぎり HTML 形式のものを

	    <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 のバイナリパッケージ全部に収録されているわけではないということです。
	  </footnote> <tt>/usr/share/doc/<var>package</var></tt>、

	  <!-- Other formats such as PostScript may be provided at your
	  PostScript のような他の形式は自分の好みで提供してください。</p>

      <sect id="copyrightfile">
	<!-- <heading>Copyright information</heading> -->

	  <!-- Every package must be accompanied by a verbatim copy of its
	  copyright and distribution license in the file
	  /usr/share/doc/&lt;package-name&gt;/copyright. This file must
	  neither be compressed nor be a symbolic link.-->
	   /usr/share/doc/&lt;package-name&gt;/copyright に収録されていなければいけません。

	    訳注:本節後半の GPL ほかの項参照
	  <!-- 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 メンテナの名前を載せるべきです。
	    <!-- 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>
	  <!-- /usr/share/doc/&lt;package-name&gt; 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
	  /usr/share/doc/&lt;package-name&gt; は、シンボリックリンクの相手先と同じソースファイルから作成されたものであること、および相手先に対して
	  "Depends" で依存していることが宣言されていること、の二つの条件を満たすときのみ、シンボリックリンクとすることができます。

	  <!-- 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/GPL, and
	  パッケージがカリフォルニア大学バークレイ校の BSD ライセンス、
	  Artistic Licence、GNU の GPL、GNU の LGPL に基づいて配布されている場合には、おのおの
	  /usr/share/common-licenses/LGPL の各ファイルを参照するように

	      <!-- 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)』であって『著作権
	      <tt>/usr/doc/copyright</tt> に全パッケージの著作権情報
	      と上記 4 つ (GPL、LGPL、Artistic と BSD)

	       から "licenses" に名称を変更しました。
	      <!-- 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 は結局のところ『ライセンス』であって文書ではないからです。
	      <!-- ちょっと意訳 -->
	  </footnote> してください。

	  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>README.Debian</tt> やその他の適切な場所にインストールされるべきです。


	<!-- <heading>Examples</heading> -->

	  <!-- 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&#45;&#45;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> が

      <sect id="instchangelog">
	<!-- <heading>Changelog files</heading> -->
	<heading>Changelog ファイル</heading>

	  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
	  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 ファイルがあれば、それは
	  changelog ファイルが HTML 形式で配布されているならば
	      Rationale: People should not have to look into two
	      places for upstream changelogs merely because they are
	      in HTML format.-->
	      原則の解説: 元が HTML 形式だからといって、上流の changelog

	  、<tt>changelog.gz</tt> は
	  <tt>lynx -dump -nolist</tt> で作成すべきです。上流の changelog

	  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> を使って圧縮してインストールすべきです。

	  <!-- 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
	  上流の開発者と Debian メンテナが同一人物であるため Debian
	  changelog と元々の changelog が一つの changelog となっている場合は、
	  changelog は
	  changelog がない場合にも、Debian の changelog は
	  <tt>changelog.Debian.gz</tt> のままにしてください。<P>

Seiji Kaneko                         skaneko@xxxxxxxxxxxx