Gentoo Linux 開発者 HOWTO

1. Portageツリー

はじめに 

Portageツリーは通常 /usr/portageの下にあり、指定 のパッケージ・ディレクトリに続づけて分類ディレクトリの階層的な構造で構 成されます。 たとえば、util-linux-2.11g.ebuild は /usr/portage/sys-apps/util-linuxディレクトリにあります。 そこには、util-linux-2.11g.ebuildと一緒に util-linuxのいくつかのebuildファイルのバージョンがあるかもしれ ません。 それは、特定のパッケージ(不規則バージョンなし)用のebuildファ イルはすべて、/usr/portageの中の同じ mycat/mypkgディレクトリを共有するからです。

CVSからPortageツリーのチェックアウト 

もし、あなたがCVSシステムに不案内なら、詳しくは CVS Tutorialをチェックしてください。

Portageツリーはgentoo-x86パッケージのGentoo Linuxツリーにありま す。パッケージ(やや大きめです)をチェックするために、最初に上記のガイドに よってCVSをセットアップし、次に、gentoo-x86ツリーをチェックアウ トします。

なにをPortageツリーに置くか(または置かないか) 

あらゆるebuildを書く前に、あなたが書こうとしているebuildに該当するもの が既にPortageツリーの中に入っていないことをbugs.gentoo.orgで チェックして下さ い。 bugs.gentoo.orgへ行き, productで"Gentoo Linux"、componentで"ebuilds"を選択して質問を決定して ください。 検索項目にはebuildの名前を置き、ステータスとしてNEW、 ASSIGNED、REOPENEDおよびRESOLVED(RESOLVEDは重要です)を選択したうえで質 問をサブミットします。

通常、Portageツリーはパッチやサンプル設定ファイルのような、比較的小さ い関連する.ebuildファイルの保存に使用します。 メインの mycat/mypkgディレクトリを混乱を避けて、これらのタイプのファ イルは、 /usr/portage/mycat/mypkg/filesディレクトリに置く べきでしょう。 さらに、開発者がCVSにバイナリ(非ASCII)ファイルを加える ことはよくないと言えます。 しかし、どうしてもこれが必要な場合(例えば、 何らかの理由でグラフィック用の小さなPNGを加える必要があれば）、 -kbオプションの使用することによりCVSにそれを追加します:

# cvs add -kb myphoto.png

-kb-kbオプションは、myphoto.pngが特別にバイナリファ イルで扱われるべきであるとCVSに伝えます。たとえば、バイナリファイルの2 つの異なるバージョンのマージが起こることが許されないことは明白です。 さらに、変更マージについて言えば、Portageに加えるどんなパッチも通 常は圧縮しないこととします。 これによりCVSは変更マージが可能と なり、矛盾があれば開発者に正確に通知できることとなります。

安定しているものとしてコミットされた時、コミットするパッケージがエンド ユーザのために「箱から取り出す」準備ができているに違いないとい うことを覚えておいてください。 パッケージを使用する大多数のシステムおよびユーザを満たすデフォルト・セッ ティングの、より良い設定がなされていることを確認してください。 あなたのパッケージが壊れており、正常でなかった場合、それを動作させる方 法や、パッケージの自分のバージョンを行った他のいくつかのディストリビュー ションをチェックして下さい。 MandrakeまたはDebianの例を参考に してチェックしてみてください。

CVSにコミットする場合、開発者はそれらのebuildをcvs commitする代 わりにrepoman commitコマンドを使用するべきです。 コミットする前に、lintoolにあなたの要約、変更記録およびebuildを 通してください。

CVSコミット方針 

• コミットする前に、常にrepomanでスキャンを実行してください。
• コミットする前に、lintoolを実行してください。
• あなたがコミットする前に、常に'emerge --pretend glibc'を行ないpackage.maskがOKであるテストをして、それが矛盾を含まないことをチェックします。
• コミットする前に、常に更新記録をアップデートすること。
• あなたがpackage.maskをコミットする間に矛盾が生じる場合に備え、パッケー ジのアップデートの前に、最新のpackage.maskを常にコミットするようにして ください。
• 常に最小限のコミットで。もし、新規のライセンスでコミットする場合、ユー ザのインストール状態を破壊したくなければ、それをマスクして、最初に改訂 されたpackage.maskをコミットしてください。さらにebuild、変更記録、使い たいライセンスの順に行ないます。

ファイルディレクトリ 

前述のとおり、各パッケージのもとではサブディレクトリは filesディレクトリです。 パッケージに要求される全てのパッ チ、設定ファイルあるいは他の付随的なファイルも、このディレクトリに納め られるべきものです。 mypkg-1.0-gentoo.diffのようなバージョ ンに特有の名前で、 パッケージを単にビルドさせるためにあなた自身が作る パッチが指定されることも考慮したいでしょう。 さらにGentoo の拡張がこのパッチは私たちGentoo Linux開発者によって作られたと皆さんに 通知されたり、メーリングリストまたはどこかほかの有力な情報元から知らさ れます。 再度いいますが、CVSがバイナリファイルでは上手く動作しないので、 これらのdiffファイルを圧縮してはなりません。

filesディレクトリの中に入れる、すべてのファイルの後ろに mypkg-1.0のようなサフィックスを加えることを考慮する結果、 あなたのebuildスクリプトの個々のバージョンのために使用された ファイル は互いから識別が可能であり、異なるリビジョン間の変更を見ることができま す。 これは一般なことであり実際によい考えです。:) よりおおざっぱ、また はきめ細かさが要求される場合は、異なるサフィックスを使用したくなること と思います。

filesディレクトリに入るべき多くのファイルを持っている場合は、 files/mypkg-1.0のような サブディレクトリを作成し適切なサ ブディレクトリにあったファイルを入れることを考えてください。 この方法 なら、 このディレクトリ(それは他の方法より便利です)中のファイルの名前 にはサフィックスを加える必要がありません。

2. ebuildスクリプト

イントロダクション 

ebuildスクリプトはPortageシステム全体の基本となるものです。 それらは、 どんなオプションのpre/postまた install/removeも実行する方法と同様に1セッ トのソースをダウンロードし、解凍し、コンパイルし、かつインストール す るのに必要な情報をすべて含んでいます。 ほとんどのPortageがPythonの中で 書かれている一方、私たちがコマンド ラインからbashのコマンドとして実行 できるよう、ebuildスクリプトはそれら自身bashの範囲で書かれています。 ebuildスクリプトの背後にある重要な設計基盤のうちの1つはこのコマンドで あることです。 アナログ的にそれらのパッケージを手動でインストールする 場合、普通はコマンドラインからタイプするでしょう。 この目的のために、 bashの構文を持っていることはよいことだと言えます。

Ebuildスクリプトはebuildとemergeコマンドによって解釈されます。 ebuildコマンドは低レベルのビルドツールと見なしてください。 それは単一の ebuildでありビルドしインストールすることは出来ますが、それ以上のもので はありません。 また、依存性を満足するかどうかチェックすることは出来ま すが、自動的な問題解決は行われません。 いっぽうemergeは、ebuild のためのハイ・レベルのエンジンであり、依存性を自動マージする能力を持ってい ますので、もし必要ならば"pretend"mergesを実行することで、どんなebuild がマージされるかなどを、さらに参照することができます。 一般に、emergeは、1つのエリア以外においてはebuildを完全 に破壊します。 ebuildで、パッケージのインストール作業(取得・解 凍・コンパイル・インストール・マージすること)手順を一度に進むことがで きます。 開発者にとって、構造プロセスの特定の部分のebuildに派生する問題を分離す ることが可能であり、非常に貴重なデバッギング・ツールとなります。

ebuildファイルの命名法 

Ebuildファイル名は4つの論理セクションから成ります:

第1のセクションはパッケージ名であり、それは英小文字、数字0-9および任意 の数のハイフン('-')で構成されています。 いくつかの例として util-linux, sysklogd およびglibcなどがあります。

第2のセクションはパッケージのバージョン(それは、メインソースのtarball 上のバージョンと通常同じはず)です。 バージョンは通常、 1.2ある いは4.5.2(非常に長いピリオドで分割された番号シーケンスもサポー トされています)のようなピリオドで分離された2つあるいは3つの数から構成 され、 最後の数字に接続して(例えば1.4bまたは2.6hのように) 一個の文字があっても構いません。 パッケージ・バージョンはハイフンでパッ ケージ名に接続します。 例えばfoo-1.0, bar-2.4.6等々。

第3(オプション)セクションは特別の接尾辞を含んでいます。 これは _alpha, _beta, _preまたは_rcの組み合わせの いずれかです。 これらの接尾辞のうち、自分の番号として (linux-2.4.0_pre10のように)どれが続いても構いません。 同一のバー ジョン部分を仮定して、_alphaパッケージは_betaより古く、 _betaは_pre、および_preは_rcより古いものと 見なします。

パッケージ名の第4の(オプション)セクションはGentoo Linux特有のリビジョ ン番号で、-r#のように指定されます。この場合の#は (package-4.5.3-r3等)整数となります。このリビジョン番号はソース のバージョンに依存せず、新しく改善された特定のGentoo Linuxリビジョンパッ ケージが利用可能であると通知するために使用されます。

既存のebuildファイルへの有益な改良を作れば、1つインクリメントされたリ ビジョン番号の新しいファイルにebuildファイルをコピーしましょう。 初期 のリリースは通常package-4.5.3のようにリビジョン番号を持っ ていません。 そしてこれはPortageによって、いわゆる0のリビジョン番号であると解釈され ます。 つまりカウントは次のように行なわれることを意味しています:1.0 (初期のバージョン)、1.0-r1, 1.0-r2など。 いつも忘れずにあなたの変更を変更記録をメンテナンスするようにし てください。 これを行なわないと、あなたのCVSアクセスが無効にされ、大変困ったことに なるかもしれません。

また、現実には私たちはebuild名の5番目のセクションを持っていると 思います。 つまり.ebuild拡張子自身です。

ebuildファイルの内容 

1. 変数の設定:

すべてのebuildファイルの第1の部品は多くの変数設定から構成されます。 セッ トすることができる変数は次のとおりです。

2. ebuildの機能

ここには、あなたのパッケージのビルドおよびインストールプロセスをコントロールするebuildファイルに定義するための様々な機能があります。

ebuildファイルを書くときの規則  

ebuildファイルは実際には単なるにシェルスクリプトですので、それらの編集 のた めにエディタのシェルスクリプトモードを使用するべきです。 タブ文字 だけ を使用して、適切なインデントを使用してください。 この場合、スペー スではありませ ん。4つのスペースでタブ・ストップを置くためにエディタが セットされていることを確認してください。 環境変数のまわりのブレースを 使用することを常に確認してください;例えば$Pと書くべきところ は${P}とします。

長い行の場合は次のように'\'を付けて折り返しを行ないます:

./configure \
	--prefix=/usr || die "configure failed"

その他の詳細に関しては、skel.ebuild(skel.ebuildの中にあり ます)を参照してください。

Vimを使用していれば、Gentooに関連するものをすべて編集する場合に正しい セッティングを使用していることを確実にするために.vimrcの最下行に次の行 を追加することができます。

if (getcwd() =~ 'gentoo-x86\|gentoo-src\|portage')
	set tabstop=4 shiftwidth=4 noexpandtab
endif

Emacsを使っているならば、.emacsrc file (for GNU Emacs) または init.el (for XEmacs)に以下の設定を記述することで、Gentoo関連の編集をするときに、 正しい設定になります。

(defun ebuild-mode ()
  (shell-script-mode)
  (sh-set-shell "bash")
  (make-local-variable 'tab-width)
  (setq tab-width 4))
(setq auto-mode-alist (cons '("\\.ebuild\\'" . ebuild-mode) auto-mode-alist))
(setq auto-mode-alist (cons '("\\.eclass\\'" . ebuild-mode) auto-mode-alist))

USE変数 

USE変数の目的は、あなたが全体的におよび自動的にあるbuild-timeオプショ ンを有効か無効にするPortageを形成することを可能にすることです。 一例と して、あなたがGNOMEファンであるとしましょう。 そうすると、コンパイル中 のオプションのGNOMEサポートのオプションを持っているすべてのebuildを好 まれると思います。 この場合、/etc/make.confの中のUSE変数にgnomeを加え ることと思います。次に、それが利用可能な場合、Portageは自動的にパッケージに オプションのGNOME対応を加えるでしょう。同様に、それらが利用可能な場合 に、オプションのGNOMEサポートをebuildに加えたくないなら、単に /etc/make.confを編集して、gnomeがUSE変数の中でセットされていないことを 確認します。 Gentoo Linuxは、あなたが望むようにシステムを形成できる数 多くのUSEオプションを持っています。

Note: あなたがUSE変数(例えばUSEからgnomeを取り除くなど) をセッ トしなおしても、これはGNOMEのbuild-timeサポートのオプションを不 能にするようにPortageに単に命じるだけです。 しかし、あなたがGNOMEを要求するebuildをemergeすれば、期 待通りパッケージは明白にGNOMEサポートを可能にするでしょう。 これは、さ らにGNOMEがまだインストールされていない場合は(依存性として)自動的にイ ンストールされるだろうということを意味します。 そのため、"実際"のemergeの前にemerge --pretendを実行する ことはうまい方法です。 取り込むパッケージを事前に知ることが出来ます。

自分のebuildsでは、use <variable>コマンドの使用により、 USE変数がセットされるかどうかチェックすることができます。 useコマンドは、USEおよびそのコマンドラインの両方の中にあ る、すべての変数の名前を出力します。 通常は以下のように使用します:

if [ "`use X`" ]; then commands; fi

USE変数も依存性をセットするためだけに使用することができます。 例えば、 あるUSE変数がセットされている場合、パッケージを単に要求したいと思うで しょう。 これはあなたのebuildのためのDEPEND変数の中でvariable? ( mycat/mypackage-1.0-r1 )の記述により行われます。 この例において、 変数がUSEの中にある場合、mycat/mypackage-1.0-r1は 単に要求されるだけです。あたの作成したebuildがこの構文を使い、"if"構文 を使っていないことを確認してください。Bashの条件式はPortage依存キャッシュ (Portage's dependency caching)に干渉してしまい、あなたのebuildを ボロボロに壊してしまいます。

次に、USEを使用する方法に関して重要なTipsを示します。 通常、パッ ケージはコンフィギュレーションステップを実施するために ./configureスクリプトを使用するでしょう。 一般的には、あなたのebuildが./configureを使用する場合、あらゆる オプションのbuild-time機能も、適切な引き数を./configureコマンド へ渡すことにより有効か無効になります。 ここに、これを扱う適切な方法があります。まず、あなたがUSEサポー トを加えたい特別の./configureオプションを探し出し、デフォルトに よりenabledまたはdisabledとします。 そしてデフォルトで enabledになる場合は、以下のような手順をとって下さい:

DEPEND="gnome? ( >=gnome-base/gnome-1.4 )
	mysql? ( >=dev-db/mysql-3.23.49 )"

src_compile() {
	local myconf
	use gnome || myconf="--disable-gnome"
	use mysql || myconf="${myconf} --disable-mysql"

	./configure ${myconf} --prefix=/usr --host=${CHOST} || die
	emake || die
}

上記では、gnomeおよびmysqlのUSE変数が無効であるか をどうかをチェックします。 use gnome || の部分は、gnomeがUSE変数に存在するか テストし、そうでなければ次にmyconf="--disable-gnome"にセットします。 このパッケージについては、それらが両方ともデフォルトにより有効になるの で、明示的にGNOMEまたはMySQLを有効にする必要はありません。 しかしなが ら、特定の組み込みがデフォルトにより無効になる場合、次のアプローチ方法 を用いてもかまいません:

DEPEND="gnome? ( >=gnome-base/gnome-1.4 )
	mysql? ( >=dev-db/mysql-3.23.49 )"

src_compile() {
	local myconf
	use gnome && myconf="--enable-gnome"
	use mysql && myconf="${myconf} --enable-mysql"

	./configure ${myconf} --prefix=/usr --host=${CHOST} || die
	emake || die
}

この時、それぞれUSE変数でセットされている場合でも、明示的にGNOME とMySQLサポートを可能にします。 use mysql &&部分はUSE変数にmysqlがあるなしに拘わらず、 myconf="${myconf} --enable-mysql"の設定をテストします。

USE変数の常時更新の最新テーブルは、ここを参照してください。

3. ファイルシステムの配置

FHSとは 

Gentoo Linuxの中で使用されるファイルシステム・レイアウトの標準は FHS(Filesystem Hierarchy Standardの略)に準拠します。 標準のシンプルな記述はここで記述しますが、完全な詳細については、 http://www.pathname.com/fhs/を参照して下さい。

いかにあなたのパッケージをファイルシステムの中へあてはめるか  

通常、パッケージがautoconfおよびautomakeを使用する場合、デフォルトのイ ンストール先は少数の例外を除いて適切になっています。

• あなたが、/bin, /sbin,/usr/binあるいは /usr/sbinへプログラムをインストールしていれば、プログラムの対応 するmanページが/usr/share/manのツリーへインストールされるべきでしょう。 これはebuildの中の./configure --mandir=/usr/share/manの指定により大抵の場合 は行なえます。
• X11、GNOMEあるいはKDEに特有のプログラムかツールに関係していたとして もGNU infoファイルは/usr/share/infoに常にインストールされるべきです。 重要事項:/usr/share/infoはGNU infoファイルのための唯一の公式な 場所です。 ほとんどの./configureスクリプトが自動的に/usr/infoにGNU infoファイルをインストールすることになるので、./configureに --infodir=/usr/share/info引数で呼ぶことは、多くの場合に必要になります。
• ドキュメンテーション・ファイルは、特定のプログラム名、バージョンおよ びリビジョンを反映するサブディレクトリの/usr/share/docに インストールされます。 これはGNOME、KDE、X11およびコンソール等々、すべ てのプログラムに当てはまります。しかしながら、いくつかのプログラムは補 足のドキュメンテーションおよびサポートファイルを、自分の目的にあった /usr/shareの階層へインストールするかもしれません。
• X11に特有のプログラムおよびライブラリは、/usr/X11R6に直接ではなく /usrへインストールされるべきです。 私たちは、Xウィンドウ・ システムのバージョン11リリース6自体のために /usr/X11R6の階層を確保しておきます。これは恐らく他のディ ストリビューションが作ったFHSの拡大解釈です。
• GNOMEとKDEのプログラムは、同様に/usrへ常にインストールさ れるべきです。

一般的には、ebuildsに/usrツリーへそれらのファイルをインス トールさせるべきでしょう。 いくつかのプログラムはGNOME、KDEおよ びX11ライブラリ(それらは混乱の原因となる)を使用、または使用せずにコン パイルしリンクすることができます。 私たちの解決方法は、ebuild作者の曖 昧さおよび不必要な複雑さを回避するために、/usrへすべてを インストールすることです。 プログラムのファイルをインストールする位置は、特定のUSE変数の存 在か不在かに依存してはいけません。したがって、Portageツリーの ebuildは、ほとんど常に排他的に/usr階層へインストールする ことにします。

4. Portageスクリプトとユーティリティ群

公開スクリプト 

これらはパッケージをインストールし削除し、かつパッケージ・データベース を維持するためにシステム管理者によって使用されるスクリプトです。

ebuildはPortageシステムの主要なエンジンです。それは、解凍し、コンパイ ルし、インストールし、マージし、マージの解消するような主なタスクをすべ て実行します。 これはebuild path/to/package.ebuild commandのような形式 でコマンドが呼び出されます。 利用可能なコマンドは次のとおりです。

注:アスタリスク(*)のあるコマンドは、通常、開発者により使用されるも のです。

emergeeは再帰的にあなたのファイルシステムへパッケージおよびその 依存性のすべてをマージします。 このコマンドは多くのオプションを持って います。emerge --helpコマンドを試してしてみて下さい。

env-updateは、インストールされたパッケージによって行なわれた変更を含め るために(/etc/ld.so.confおよび /etc/profile.envに制限されずに取り込まれた) コンフィグレー ションファイルを更新します。

内部スクリプトとコマンド群 

これらは共通のタスクを実行するためにebuildファイルの中で使用することが できるスクリプトです。

より詳細な指示については、/usr/lib/portage/binにあるスク リプト自身を参照してください。

5. パッケージの依存関係

なぜ依存性が重要か 

Portageは便利なスクリプトである以上に、あなたのどんなプロジェクト(プロ グラムやライブラリ) の構築方法に統一性を与えます。さらに、あなたが ebuildの中でこれらを注意深く指定すれば、それはどんな必要な依存関係も取 得してインストールします。

公式のebuildsでは、全部の依存関係が既に指定されています。 したがって、 あなたがemerge net-www/mozilla/mozilla-1.0のコマンドを発行する時、 Portageは Mozilla自身が構築される前にMozillaの構築および実行するのに必 要なライブラリがすべて適切にインストールされることを保証できます。

Portageは構築時依存関係とランタイム依存関係をさらに識別します。 (警告: 現在、Portageは構築時およびランタイム依存関係をすべてインストールする 場合の成り行きにまかせています。 あとの段階では、ランタイム依存関係だ けがインストールされており、あなたのインストールを整えることが可能でしょ う)。

いかにしてebuildファイルの依存性を指定するか  

foo-x.y.z.ebuild内のDEPEND変数は、foo を構築するために必要なパッケージをPortageへ伝えます。RDEPEND変 数は、fooを実行するためにどのパッケージが必要かを明示しま す。 例えば:

DEPEND="virtual/glibc
        sys-libs/zlib"
RDEPEND="virtual/glibc"

これはPortageにfoo-x.y.zを構築するように命令するのには、パッケージ virtual/glibc(ビット中のvirtualsについて詳細) および sys-libs/zlibは必要です。それは、どれに関して必要なglibc あるいはzlibのバージョンであるかについて言及していません。それは"何で も実行"することを意味します。

"何でも行く"にはもちろん少し恐い気がしますし、一般的な場合はうまく働か ないでしょう。 glibc(それは100%バイナリのために非常に忙しく働きます)の よう中心となるライブラリが必要としないならば、それは現実に作動します。 他のライブラリについても、もちろんバージョン依存性を指定することができ ます。これを行なうためには多数の方法があります:

>=sys-apps/bar-1.2
=sys-apps/baz-1.0

>=と=は、あなたが期待するように動作します。 sys-apps/bar バージョン 1.2か、より新しいく(sys-apps/bar-2.0ならOKという意味)、sys-apps/bazバー ジョン1.0が受け入れられるただ一つのバージョンであるならOKです。

Portageは、バージョン番号への4つの特別の接尾辞のことを知っています。 -rX, -preX,-alphaXおよび-betaX-rX等(この場 合のXはあなたの好きな数字)です。 >=sys-apps/foo-1.0の条件は以下のようになります。

sys-apps/frob-1.0-r1
sys-apps/frob-1.0
sys-apps/frob-1.0_pre1
sys-apps/frob-1.0_beta1
sys-apps/frob-1.0_alpha1

Portageはリストされた順に内部で調整し、先頭であるものを選択するでしょ う。 これは_alphaXより_beta,_betaXより _preX、_preXよりサフィックスなし、サフィックスなしより -rXを採用することを意味します。

バージョン依存性を指定する他の方法について、次にあげておきます:

~sys-apps/qux-1.0
=sys-apps/foo-1.2*

~sys-apps/qux-1.0 は、qux-1.0の最新のリビジョンを選択するでしょう。

=sys-apps/foo-1.2* は1.2のシリーズの中で最新のメンバーを選択しますが、 1.3以降のシリーズを無視するでしょう。 すなわち、foo-1.2.3および foo-1.2.0は両方とも有効であるのに対し、foo-1.3.3およびfoo-1.3.0は無視 されることになります。

6. テストおよび展開

変更記録 

さらに、ebuildを更新する(あるいは新しく書く)場合は常に、その変更記録を 更新(あるいは新しく作成)しなければなりません。 skel.ChangeLogは、ベースとして使用してもよい変更記録のサ ンプルを含んでいます。

変更記録の目的は、「何が」「なぜ」「誰によって」 行われているか文書で明らかにすることです。これは、開発者およびユーザの 両方が容易な方法で行なわれた変更をトレースすることを可能にします。

変更記録は、まずユーザをターゲットにしています。したがってあなたが書くために必ず守るポイントとして、短いこと、また内部技術的な詳細に関して冗長を避けます。

有用なテストツール 

私たちはあなたのebuildの記述やメンテナンスの助けとなる有用なツールをい くつか用意しています。

• lintool - 変更記録と要約のファイルの構文的な確認のためのebuildのチェック。
• change - Can create a new ChangeLog or add an entry to an existing one.
• gentool-bump-revision - 開発者専用ツール これはリビジョン番号に対照してCVSに新しい修正を加えるとともに古い修正を削除し、変更記録を適切に更新します。
• repoman - 開発者専用ツール CVSチェックイン手続きを支援するものです。