Developer's Reference chap.8

[Yoshizumi Endo <y-endo@xxxxxxxxxxxxxxx>]

遠藤です。

Debian デベロッパーズリファレンス第 8 章の翻訳です。
チェックお願いします。

|     <chapt id="porting">Porting and Being Ported
|       <p>
| Debian supports an ever-increasing number of architectures.  Even if
| you are not a porter, and you don't use any architecture but one, it
| is part of your duty as a maintainer to be aware of issues of
| portability.  Therefore, even if you are not a porter, you should read
| most of this chapter.

    <chapt id="porting">移植作業と移植版
      <p>
Debian がサポートするアーキテクチャは今なお増加しています。
移植作業者でない場合や、特定のアーキテクチャ以外を利用しない場合でも、
開発者としてポータビリティの問題を意識しておくことは必要でしょう。
そのため、移植作業者でない方も、こちらの章はあらかた読んでおくべきです。

|       <p>
| Porting is the act of building Debian packages for architectures which
| is different from the original architecture of the package
| maintainer's binary package.  It is a unique and essential activity.
| In fact, porters do most of the actual compiling of Debian packages.
| For instance, for one <em>i386</em> binary package, there has to be a
| recompile for each architecture, which is around five more builds.

      <p>
移植作業とは、パッケージ開発者のバイナリパッケージがビルドされた
元のアーキテクチャとは異なるアーキテクチャ向けに Debian 
パッケージをビルドすることを指します。
こちらは独自の重要な活動です。
事実、大半の Debian パッケージを実際にコンパイルしているのは移植作業者です。
例えば、<em>i386</em> 用のバイナリパッケージ一つにしても、
各アーキテクチャ用に再コンパイルする必要がありますし、
そのためにはおよそ五回以上ビルドを行なわなければなりません。

|       <sect id="kind-to-porters">Being Kind to Porters
| 	<p>
| Porters have a difficult and unique task, since they are required to
| deal with a large volume of packages.  Ideally, every source package
| should build right out of the box; unfortunately, this is often not
| the case.  This section contains a checklist of ``gotchas'' often
| committed by Debian maintainers -- common problems which often stymie
| porters, and make their jobs unnecessarily more difficult.

      <sect id="kind-to-porters">移植作業者への配慮
	<p>
移植作業者は、膨大な数のパッケージを処理しなければならないために、
困難な独自の作業を行ないます。
理想としては、全ソースパッケージがさまざまなアーキテクチャで
適切にビルドされるべきなのですが、残念ながらそううまくは行きません。
この節では、Debian 開発者らによってしばしば指摘される「既知」の確認項目
-- 移植作業者を困らせたり、
その作業を不必要に困難にさせる共通の問題を取り上げます。

| 	<p>
| The first and most important watchword is to respond quickly to bug or
| issues raised by porters.  Please treat porters with courtesy, as if
| they were in fact co-maintainers of your package (which in a way, they
| are).

	<p>
まず第一に上げられる最も重要なモットーは、
移植作業者によって指摘されたバグや問題には素早く対応するということです。
移植作業者に対しては、
ご自分のパッケージの実際の協同開発者に対するのと同じように、
丁重に対応してください。(ある意味では彼らは協同開発者です。)

| 	<p>
| By far, most of the problems encountered by porters are caused by
| <em>packaging bugs</em> in the source packages.  Here is a checklist
| of things you should check or be aware of.

	<p>
実際、移植作業者が出くわす問題の大半は、
ソースパッケージにおける<em>パッケージング上のバグ</em>なのです。
以下が確認し注意すべき事柄の確認項目です。

| <enumlist>
| 	    <item>
| Don't set architecture to a value other than ``all'' or ``any'' unless
| you really mean it.  In too many cases, maintainers don't follow the
| instructions in the <url
| id="http://www.debian.org/doc/packaging-manuals/packaging.html/";
| name="Debian Packaging Manual">.  Setting your architecture to ``i386''
| is usually incorrect.

<enumlist>
	    <item>
``all'' や ``any'' 以外の値をアーキテクチャとして設定することは、
そのことを本当に意図していない限り、行なわないでください。
大変多くのケースで、開発者が
<url id="http://www.debian.org/doc/packaging-manuals/packaging.html/";
name="Debian パッケージングマニュアル">
の説明にしたがっていません。
アーキテクチャを ``i386'' に設定することは、たいていのところ間違いです。

| 	    <item>
| Make sure your source package is correct.  Do <tt>dpkg-source -x
| <var>package</var>.dsc</tt> to make sure your source package unpacks
| properly.  Then, in there, try building your package from scratch with
| <tt>dpkg-buildpackage</tt>.

	    <item>
作成したソースパッケージが正しいものであることを確認してください。
<tt>dpkg-source -x <var>package</var>.dsc</tt> を実行して、
ご自分のソースパッケージが適切に展開できることを確認してください。
それから、そこで <tt>dpkg-buildpackage</tt> を用い、
一からご自分のパッケージをビルドしてみてください。

| 	    <item>
| Make sure you don't ship your source package with the
| <file>debian/files</file> or <file>debian/substvars</file> files.
| They should be removed by the `clean' target of
| <file>debian/rules</file>.

	    <item>
<file>debian/files</file> ファイルや <file>debian/substvars</file>
ファイルを残したまま、ソースパッケージをアップロードしないでください。
これらのファイルは、<file>debian/rules</file> の `clean' 
ターゲットによって消去されていなければなりません。

| 	    <item>
| Make sure you don't rely on locally installed or hacked configurations
| or programs.  For instance, you should never be calling programs in
| <file>/usr/local/bin</file> or the like.  Try not to rely on programs
| be setup in a special way.  Try building your package on another
| machine, even if it's the same architecture.

	    <item>
ローカルにインストールされたり手を加えられた
設定やプログラムに依存していないことを確かめてください。
例えば、<file>/usr/local/bin</file> 
やそれに類するディレクトリにあるプログラムを呼び出してはいけません。
特別に設定されたプログラムに依存しないようにしてください。
また、ご自分のパッケージを
同一アーキテクチャの他のマシンでビルドしてみてください。

| 	    <item>
| Don't depend on the package your building already being installed (a
| sub-case of the above issue).

	    <item>
(上記のことにも含まれることですが、)
ご自分でビルドされたパッケージを既にインストールされているものと
仮定してはいけません。

| 	    <item>
| Don't rely on <prgn>egcc</prgn> being available; don't rely on
| <prgn>gcc</prgn> being a certain version.

	    <item>
<prgn>egcc</prgn> が利用できるものと仮定してはいけません。
また、特定のバージョンの <prgn>gcc</prgn> に依存してはいけません。

| 	    <item>
| Make sure your debian/rules contains separate ``binary-arch'' and
| ``binary-indep'' targets, as the Debian Packaging Manual requires.
| Make sure that both targets work independently, that is, that you can
| call the target without having called the other before. To test this,
| try to run <tt>dpkg-buildpackage -b</tt>.
| 	  </enumlist>

	    <item>
Debian パッケージングマニュアルで要求されている通りに、
``binary-arch'' ターゲットと ``binary-indep'' ターゲットは
debian/rules に別々に収録しなければなりません。
この両ターゲットがそれぞれ独立して動作すること、
つまり、あるターゲットを呼び出す際に
他のターゲットを前もって呼び出していないことをを確認してください。
こちらをテストするには、<tt>dpkg-buildpackage -b</tt>
を実行してみてください。
	  </enumlist>

|       <sect id="porter-guidelines">Guidelines for Porter Uploads
| 	<p>
| If the package builds out of the box for the architecture to be ported
| to, you are in luck and your job is easy.  This section applies to
| that case; it describes how to build and upload your binary NMU so
| that it is properly installed into the archive.  If you do have to
| patch the package in order to get it to compile for the other
| architecture, you are actually doing a source NMU, so consult <ref
| id="nmu-guidelines"> instead.

      <sect id="porter-guidelines">移植作業者によるアップロードに関するガイドライン
	<p>
移植先のアーキテクチャ用のバイナリのみを運よくビルドできるならば、
作業もはかどるでしょう。
この節で扱うのはこのようなケースです。
つまり、適切にアーカイブにインストールできるように、
バイナリをビルドし binary NMU をアップロードする方法を説明します。
他のアーキテクチャ向けにコンパイルを通すために、
パッケージにパッチを当てなくてはならない場合は、
source NMU を行なわなければなりません。
こちらに関しては <ref id="nmu-guidelines"> をご参照ください。

| 	<p>
| In a binary NMU, no real changes are being made to the source.  You do
| not need to touch any of the files in the source package.  This
| includes <file>debian/changelog</file>.

	<p>
binary NMU を行なう場合、そのソースに対しては一切変更を行ないません。
ソースパッケージ中のいかなるファイルに対しても手をつける必要はありません。
<file>debian/changelog</file> も然りです。

| 	<p>
| Sometimes you need to recompile a packages against other packages
| which have been updated, such as libraries.  You do have to bump the
| version number in this case, so that the upgrade system can function
| properly.  Even so, these are considered binary-only NMUs -- there is
| no need in this case for all architectures to recompile.  You should
| set the version number as in the case of NMU versioning, but add a
| ``.0.'' before the the NMU version.  For instance, a recompile-only
| NMU of the source package ``foo_1.3-1'' would be numbered
| ``foo_1.3-1.0.1''.

	<p>
場合によっては、ライブラリなどの更新済みの他パッケージに対して、
あるパッケージを再コンパイルする必要があるでしょう。
この場合は、アップグレードシステムが適切に動作するように、
バージョン番号を上げなければなりません。
しかしながら、たとえそうでも、これらは binary のみの NMU とみなされます。
-- この場合、全アーキテクチャで再コンパイルする必要はないからです。
NMU の場合と同様にバージョン番号を設定しなければなりませんが、
この場合は NMU バージョンの前に ``.0.'' を付け加えます。
例えば、``foo_1.3-1'' というソースパッケージを単に再コンパイルして NMU
する場合、その番号は ``foo_1.3-1.0.1'' になります。

| 	<p>
| The way to invoke <prgn>dpkg-buildpackage</prgn> is as
| <tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>.  Of course,
| set <var>porter-email</var> to your email address.  This will do a
| binary-only build of only the architecture-dependant portions of the
| package, using the `binary-arch' target in <file>debian/rules</file>.

	<p>
<prgn>dpkg-buildpackage</prgn> を起動するには、
<tt>dpkg-buildpackage -B -m<var>porter-email</var></tt>
としてください。
もちろん <var>porter-email</var> の箇所には
ご自分の電子メールアドレスを当てはめてください。
こうすれば、<file>debian/rules</file> の `binary-arch' 
ターゲットを用いて、該当パッケージの特定アーキテクチャ依存部分に限った
バイナリビルドのみが行なわれます。

| 	<sect1 id="source-nmu-when-porter">
| 	  <heading>When to do a source NMU if you are a porter</heading>
| 	  <p>
| Porters doing a source NMU generally follow the guidelines found in
| <ref id="nmu">, just like non-porters.  However, it is expected that
| the wait cycle for a porter's source NMU is smaller than for a
| non-porter, since porters have to cope with a large quantity of
| packages.

	<sect1 id="source-nmu-when-porter">
	  <heading>移植作業者が source NMU を行なう場合には</heading>
	  <p>
移植作業者が source NMU を行なう場合、
非移植作業者の場合と同様に、一般的には
<ref id="nmu"> にて触れたガイドラインに従います。
しかしながら、移植作業者の場合、
相当な量のパッケージを処理しなければならないことから、
source NMU をする際に他の開発者の対応を待つ時間は、
非移植作業者の場合よりも短いことが望まれています。

| 	  <p>
| Again, the situation varies depending on the distribution they are
| uploading to.  Crucial fixes (i.e., changes need to get a source
| package to compile for a released-targeted architecture) can be
| uploaded with <em>no</em> waiting period for the `frozen' distribution.

	  <p>
さらに、その状況は
アップロード先のディストリビューションによっても異なってきます。
`frozen' ディストリビューションへの重要な修正
(すなわち、リリースが予定されているアーキテクチャで
ソースパッケージのコンパイルを通すために必要となる修正) は、
待ち時間を<em>置かず</em>にアップロードすることができます。

| 	  <p>
| However, if you are a porter doing an NMU for `unstable', the above
| guidelines for porting should be followed, with two variations.
| Firstly, the acceptable waiting period -- the time between when the
| bug is submitted to the BTS and when it is OK to do an NMU -- is seven
| days for porters working on the unstable distribution.  This period
| can be shortened if the problem is critical and imposes hardship on
| the porting effort, at the discretion of the porter group.  (Remember,
| none of this is Policy, just mutually agreed upon guidelines.)

	  <p>
移植作業者が `unstable' ディストリビューションへの NMU を行なう場合も、
上記の移植作業に関するガイドラインに従わなければなりませんが、
二点ほど異なる点もあります。
まず一点目は、十分とされる待ち時間 -- BTS にバグが報告されてから、NMU
が認められるまでの時間 -- が、`unstable'
ディストリビューションに関する作業を行なう移植作業者の場合、7 
日間であるということです。
なお、この期間も、
致命的な問題や移植作業の負担となる問題がある場合は、
移植作業グループの裁量で短くされることもありえます。
(これはポリシーではなく、
あくまでもガイドラインに沿って相互に了承されているものです。
ご注意ください。)

| 	  <p>
| Secondly, porters doing source NMUs should make sure that the bug they
| submit to the BTS should be of severity `important' or greater.  This
| ensures that a single source package can be used to compile every
| supported Debian architecture by release time.  It is very important
| that we have one version of the binary and source package for all
| architecture in order to comply with many licenses.

	  <p>
二点目は、source NMU を行なう移植作業者が BTS に報告する際、
そのバグの重要度を `important' 以上にしなければならないということです。
こうすることによって、リリース時に Debian
でサポートされる全アーキテクチャ用のバイナリが、
確実に単一のソースパッケージから構築されることが確実になります。
さまざまなライセンスに準拠するためにも、
全アーキテクチャにわたるバイナリおよびソースパッケージを
単一のバージョンで管理することは、極めて重要です。

| 	  <p>
| Porters should try to avoid patches which simply kludge around bugs in
| the current version of the compile environment, kernel, or libc.
| Sometimes such kludges can't be helped.  If you have to kludge around
| compilers bugs and the like, make sure you <tt>#ifdef</tt> your work
| properly; also, document your kludge so that people know to remove it
| once the external problems have been fixed.

	  <p>
移植作業者は、現行バージョンのコンパイル環境や、カーネル、libc 
においてのみバグが回避できるようなパッチを、
避けるように努めなければなりません。
ただ、このような応急処置が必要になる場合もあるでしょう。
コンパイラのバグやその類いを回避しなければならない場合、
そのために追加したコードには適切に <tt>#ifdef</tt> を用いてください。
また、その外的な問題が修正された際に誰もがその箇所を除去できるように、
ご自分が行なった応急処置を文書に残しておいてください。

| 	  <p>
| Porters may also have an unofficial location where they can put the
| results of their work during the waiting period.  This helps others
| running the port have the benefit of the porter's work, even during
| the waiting period.  Of course, such locations have no official
| blessing or status, so buyer, beware.

	  <p>
他の開発者の対応を待つ間に、移植作業者は
自身の作業結果を公開するために非公式な場所を構えることもあります。
このことは、他の開発者の対応を待つ間においても、
その移植作業の利益を、同じ作業に携わる他の開発者が
受け取れる利点があります。
もちろん、このような場所は公式に推奨されるものでも
公式な地位を与えられたものでもありませんので、
こちらを利用される場合はご注意ください。

|       <sect>Tools for Porters
| 	<p>
| There are several tools available for the porting effort. This section
| contains a brief introduction to these tools; see the package
| documentation or references for full information.

      <sect>移植作業者用のツール群
	<p>
移植作業に有用なツールがいくつか用意されています。
この節ではこれらツール群の簡単な紹介を行ないます。
なお、これらに関する完全な情報については、
各パッケージの文書やリファレンスをご覧ください。

| 	<sect1 id="quinn-diff">
| 	  <heading><package>quinn-diff</package>
| 	  <p>
| <package>quinn-diff</package> is used to locate the differences from
| one architecture to another.  For instance, it could tell you which
| packages need to be ported for architecture <var>Y</var>, based on
| architecture <var>X</var>.

	<sect1 id="quinn-diff">
	  <heading><package>quinn-diff</package>
	  <p>
<package>quinn-diff</package> は、
異なるアーキテクチャ間の差異を locate するために用いられます。
例えば、アーキテクチャ <var>X</var> からアーキテクチャ <var>Y</var> へ、
どのパッケージを移植する必要があるのかを教えてくれます。

| 	<sect1 id="buildd">
| 	  <heading><package>buildd</package>
| 	  <p>
| The <package>buildd</package> system is used as a distributed,
| client-server build distribution system.  It is usually used in
| conjunction with <em>auto-builders</em>, which are ``slave'' hosts
| which simply check out and attempt to auto-build packages which need
| to be ported.  There is also an email interface to the system, which
| allows porters to ``check out'' a source package (usually one which
| cannot yet be autobuilt) and work on it.

	<sect1 id="buildd">
	  <heading><package>buildd</package>
	  <p>
<package>buildd</package> システムは、分散配置される
クライアント/サーバ式のビルドおよびディストリビューションシステム
として用いられます。
こちらは通常 <em>auto-builders</em> と共に利用されます。
この <em>auto-builders</em> は、単に移植の必要なパッケージのチェックアウトと
自動ビルドを行なう「スレーブ」ホストです。
このシステムには、
移植作業者がソースパッケージを「チェックアウト」して作業を行なうための
電子メールインターフェイスもあります。

| 	  <p>
| <package>buildd</package> is not yet available as a package; however,
| most porting efforts are either using it currently or planning to use
| it in the near future.  It collects a number of as yet unpackaged
| components which are currently very useful and in use continually,
| such as <prgn>andrea</prgn>, <prgn>sbuild</prgn> and
| <prgn>wanna-build</prgn>.

	  <p>
<package>buildd</package> はまだパッケージとしては利用できませんが、
移植作業の多くにおいて現に利用されており、
また近い将来利用されることが計画されています。
こちらには、現に極めて有用で頻繁に利用されている
<prgn>andrea</prgn> や、<prgn>sbuild</prgn>、
<prgn>wanna-build</prgn> 
といったパッケージ化されていない数々のコンポーネントが含まれています。

| 	  <p>
| Some of the data produced by <package>buildd</package> which is
| generally useful to porters is available on the web at <url
| id="&url-buildd;">.  This data includes nightly updated information
| from <prgn>andrea</prgn> (source dependencies) and
| <package>quinn-diff</package> (packages needing recompilation).

	  <p>
<package>buildd</package> によって生成された
移植作業者にとって一般的に有益なデータのいくつかは、
ウェブ上の <url id="&url-buildd;"> で利用できます。
こちらのデータには、毎晩 <prgn>andrea</prgn> (ソースの依存関係) と
<package>quinn-diff</package> (再コンパイルの必要なパッケージ) 
から更新される情報も収録されています。

| 	  <p>
| We are very excited about this system, since it potentially has so
| many uses.  Independent development groups can use the system for
| different sub-flavors of Debian, which may or may not really be of
| general interest (for instance, a flavor of Debian built with gcc
| bounds checking).  It will also enable Debian to recompile entire
| distributions quickly.

	  <p>
さまざまな用途に役立つ可能性を秘めているこのシステムに、
私たちは大きな期待を寄せています。
一般的的な関心を呼ぶかどうかは別ですが、独立した各開発グループが、
Debian の異なるサブ flavor 用のシステム
(例えば、gcc バウンズチェック付きでビルドされた Debian のある flavor など)
を利用することもできます。
また、こちらは Debian がディストリビューション全体を素早く再コンパイル
することも可能にするのです。

| 	<sect1 id="dpkg-cross">
| 	  <heading><package>dpkg-cross</package>
| 	  <p>
| <package>dpkg-cross</package> is a tool for installing libraries and
| headers for cross-compiling in a way similar to
| <package>dpkg</package>. Furthermore, the functionality of
| <prgn>dpkg-buildpackage</prgn> and <prgn>dpkg-shlibdeps</prgn> is
| enhanced to support cross-compiling.

	<sect1 id="dpkg-cross">
	  <heading><package>dpkg-cross</package>
	  <p>
<package>dpkg-cross</package> は、
<package>dpkg</package> に似た方法で、
クロスコンパイル用のライブラリやヘッダをインストールするツールです。
さらに、クロスコンパイルをサポートするために
<prgn>dpkg-buildpackage</prgn> や <prgn>dpkg-shlibdeps</prgn>
の機能性も高められています。

-- 
Yoshizumi Endo <y-endo@xxxxxxxxxxxxxxx>