Whole document tree
Debian デベロッパーズリファレンス - 移植作業と移植版
[ 前のページ ]
[ 目次 ]
[ 1 ]
[ 2 ]
[ 3 ]
[ 4 ]
[ 5 ]
[ 6 ]
[ 7 ]
[ 8 ]
[ 9 ]
[ 10 ]
[ 11 ]
[ 次のページ ]
Debian デベロッパーズリファレンス
章 8 - 移植作業と移植版
Debian がサポートするアーキテクチャは今なお増加しています。
移植作業者でない場合や、特定のアーキテクチャ以外を利用しない場合でも、
開発者としてポータビリティの問題を意識しておくことは必要でしょう。
そのため、移植作業者でない方も、こちらの章はあらかた読んでおくべきです。
移植作業とは、パッケージ開発者のバイナリパッケージが構築された
元のアーキテクチャとは異なるアーキテクチャ向けに Debian
パッケージを構築することを指します。 こちらは独自の必要な活動です。
事実、大半の Debian パッケージを実際にコンパイルしているのは移植作業者です。
例えば、i386 用にコンパイルされたバイナリパッケージを
各アーキテクチャ用に再コンパイルする必要がありますし、
そのためにはおよそ五回以上構築を行なわなければなりません。
8.1 移植作業者への配慮
移植作業者は、膨大な数のパッケージを処理しなければならないために、
困難な独自の作業を行ないます。
理想としては、全ソースパッケージがさまざまなアーキテクチャで
適切に構築されるべきなのですが、残念ながらそううまくは行きません。
この節では、Debian 開発者らによってしばしば指摘される「既知」の確認項目 --
移植作業者を困らせたり、
その作業を不必要に困難にさせる共通の問題を取り上げます。
まず第一に上げられる最も重要なモットーは、
移植作業者によって指摘されたバグや問題には素早く対応するということです。
移植作業者に対しては、
あなたのパッケージの実際の協同開発者に対するのと同じように、
丁重に対応してください。(ある意味では彼らは協同開発者です。)
実際、移植作業者が出くわす問題の大半は、
ソースパッケージにおけるパッケージング上のバグなのです。
以下が確認し注意すべき事柄の確認項目です。
-
``all'' や ``any'' 以外の値をアーキテクチャとして設定することは、
そのことを本当に意図していない限り、行なわないでください。
大変多くのケースで、開発者が
Debian
パッケージングマニュアル の説明にしたがっていません。
アーキテクチャを ``i386'' に設定することは、たいていのところ間違いです。
-
作成したソースパッケージが正しいものであることを確認してください。
dpkg-source -x package.dsc を実行して、
あなたのソースパッケージが適切に展開できることを確認してください。
それから、そこで dpkg-buildpackage を用い、
一からあなたのパッケージを構築してみてください。
-
debian/files ファイルや debian/substvars
ファイルを残したまま、ソースパッケージをアップロードしないでください。
これらのファイルは、debian/rules の `clean'
ターゲットによって消去されていなければなりません。
-
ローカルにインストールされたり手を加えられた
設定やプログラムに依存していないことを確かめてください。
例えば、
/usr/local/bin
やそれに類するディレクトリにあるプログラムを呼び出してはいけません。
プログラムが特殊な方法でセットアップされることを 当てにしないでください。
また、あなたのパッケージを、
同一アーキテクチャでもかまいませんので、他のマシンで構築してみてください。
-
(上記のことにも含まれることですが、)
あなたで構築されたパッケージをすでにインストールされているものと
仮定してはいけません。
-
egcc が利用できるものと仮定してはいけません。
また、特定のバージョンの gcc に依存してはいけません。
-
Debian パッケージングマニュアルで要求されている通りに、 ``binary-arch''
ターゲットと ``binary-indep'' ターゲットは debian/rules
に別々に収録しなければなりません。
この両ターゲットがそれぞれ独立して動作すること、
つまり、あるターゲットを呼び出す際に
他のターゲットを前もって呼び出していないことを確認してください。
こちらをテストするには、dpkg-buildpackage -b
を実行してみてください。
8.2 移植作業者によるアップロードに関するガイドライン
移植先のアーキテクチャ用のバイナリを取り出したときのままで構築できるなら、
作業もはかどるでしょう。 この節で扱うのはこのような場合で、言葉を変えれば、
適切にアーカイブにインストールできるように、 バイナリを構築し binary NMU
をアップロードする方法を説明します。
他のアーキテクチャ向けにコンパイルを通すために、
パッケージにパッチを当てなくてはならない場合は、 source NMU
を行なわなければなりません。 こちらに関しては source NMU を行なうには, Section 7.4
をご参照ください。
binary NMU を行なう場合、そのソースに対しては一切変更を行ないません。
ソースパッケージ中のいかなるファイルに対しても手をつける必要はありません。
debian/changelog も然りです。
場合によっては、ライブラリなどの更新済みの他パッケージに対して、
あるパッケージを再コンパイルする必要があるでしょう。
この場合は、アップグレードシステムが適切に動作するように、
バージョン番号を上げなければなりません。 しかしながら、たとえそうでも、これらは
binary のみの NMU とみなされます。 --
この場合、全アーキテクチャで再コンパイルする必要はないからです。 NMU
の場合と同様にバージョン番号を設定しなければなりませんが、 この場合は NMU
バージョンの前に ``.0.'' を付け加えます。 例えば、``foo_1.3-1''
というソースパッケージを単に再コンパイルして NMU する場合、その番号は
``foo_1.3-1.0.1'' になります。
dpkg-buildpackage を起動するには、 dpkg-buildpackage -B
-mporter-email としてください。 もちろん
porter-email の箇所には
あなたの電子メールアドレスを当てはめてください。
こうすれば、debian/rules の `binary-arch'
ターゲットを用いて、該当パッケージの特定アーキテクチャ依存部分に限った
バイナリ構築のみが行なわれます。
8.2.1 移植作業者が source NMU を行なう場合には
移植作業者が source NMU を行なう場合、 非移植作業者の場合と同様に、一般的には
ノンメンテナアップロード (NMU), 章 7
にて触れたガイドラインに従います。 しかしながら、移植作業者の場合、
相当な量のパッケージを処理しなければならないことから、 source NMU
をする際に他の開発者の対応を待つ時間は、
非移植作業者の場合よりも短いことが望まれています。
さらに、その状況は
アップロード先のディストリビューションによっても異なってきます。 `frozen'
ディストリビューションへの重要な修正
(すなわち、リリースが予定されているアーキテクチャで
ソースパッケージのコンパイルを通すために必要となる修正) は、
待ち時間を置かずにアップロードすることができます。
移植作業者が `unstable' ディストリビューションへの NMU を行なう場合も、
上記の移植作業に関するガイドラインに従わなければなりませんが、
二点ほど異なる点もあります。 まず一点目は、十分とされる待ち時間 -- BTS
にバグが報告されてから、NMU が認められるまでの時間 -- が、`unstable'
ディストリビューションに関する作業を行なう移植作業者の場合、7
日間であるということです。 なお、この期間も、
致命的な問題や移植作業の負担となる問題がある場合は、
移植作業グループの裁量で短くされることもありえます。 (これはポリシーではなく、
あくまでもガイドラインに沿って相互に了承されているものです。 ご注意ください。)
二点目は、source NMU を行なう移植作業者が BTS に報告する際、 そのバグの重要度を
`important' 以上にしなければならないということです。
こうすることによって、リリース時に Debian
でサポートされる全アーキテクチャ用のバイナリが、
確実に単一のソースパッケージから構築されることが保証されます。
さまざまなライセンスに準拠するためにも、
全アーキテクチャにわたるバイナリおよびソースパッケージを
単一のバージョンで管理することは、極めて重要です。
移植作業者は、現行バージョンのコンパイル環境や、カーネル、libc
においてのみバグが回避できるようなパッチを、
避けるように努めなければなりません。
ただ、このような応急処置が必要になる場合もあるでしょう。
コンパイラのバグやその類いを回避しなければならない場合、
そのために追加したコードには適切に #ifdef を用いてください。
また、その外的な問題が修正された際に誰もがその箇所を除去できるように、
あなたが行なった応急処置を文書に残しておいてください。
他の開発者の対応を待つ間に、移植作業者は
自身の作業結果を公開するために非公式な場所を構えることもあります。
このことは、他の開発者の対応を待つ間においても、
その移植作業の利益を、同じ作業に携わる他の開発者が 受け取れる利点があります。
もちろん、このような場所は公式に推奨されるものでも
公式な地位を与えられたものでもありませんので、
こちらを利用される場合はご注意ください。
8.3 移植作業者用のツール群
移植作業に有用なツールがいくつか用意されています。
この節ではこれらツール群の簡単な紹介を行ないます。
なお、これらに関する完全な情報については、
各パッケージの文書やリファレンスをご覧ください。
8.3.1 quinn-diff
quinn-diff は、 異なるアーキテクチャ間の差異を locate
するために用いられます。 例えば、アーキテクチャ X からアーキテクチャ
Y へ、 どのパッケージを移植する必要があるのかを教えてくれます。
8.3.2 buildd
buildd システムは、分散配置される
クライアント/サーバ式の構築およびディストリビューションシステム
として用いられます。 こちらは通常 auto-builders と共に利用されます。
この auto-builders は、単に移植の必要なパッケージのチェックアウトと
自動構築を行なう「スレーブ」ホストです。 このシステムには、
移植作業者がソースパッケージを「チェックアウト」して作業を行なうための
電子メールインターフェイスもあります。
buildd はまだパッケージとしては利用できませんが、
移植作業の多くにおいて現に利用されており、
また近い将来利用されることが計画されています。
こちらには、現に極めて有用で頻繁に利用されている andrea
や、sbuild 、 wanna-build
といったパッケージ化されていない数々のコンポーネントが含まれています。
buildd によって生成された
移植作業者にとって一般的に有益なデータのいくつかは、 ウェブ上の http://buildd.debian.org/
で利用できます。 こちらのデータには、毎晩 andrea
(ソースの依存関係) と quinn-diff (再コンパイルの必要なパッケージ)
から更新される情報も収録されています。
さまざまな用途に役立つ可能性を秘めているこのシステムに、
私たちは大きな期待を寄せています。
一般的的な関心を呼ぶかどうかは別ですが、独立した各開発グループが、 Debian
の異なるサブ flavor 用のシステム (例えば、gcc バウンズチェック付きで構築された
Debian のある flavor など) を利用することもできます。 また、こちらは Debian
がディストリビューション全体を素早く再コンパイル することも可能にするのです。
8.3.3 dpkg-cross
dpkg-cross は、 dpkg に似た方法で、
クロスコンパイル用のライブラリやヘッダをインストールするツールです。
さらに、クロスコンパイルをサポートするために dpkg-buildpackage や
dpkg-shlibdeps の機能性も高められています。
[ 前のページ ]
[ 目次 ]
[ 1 ]
[ 2 ]
[ 3 ]
[ 4 ]
[ 5 ]
[ 6 ]
[ 7 ]
[ 8 ]
[ 9 ]
[ 10 ]
[ 11 ]
[ 次のページ ]
Debian デベロッパーズリファレンス
ver. 2.11, 2002年04月08日
Adam Di Carlo, current maintainer aph@debian.org
Christian Schwarz schwarz@debian.org
Ian Jackson ijackson@gnu.ai.mit.edu
|