解き放たれしソフトウェア

GNU/LinuxなどFLOSSについて書いてみるつもり

【Gentoo】Portageツリーの構造を読み解く

Gentooのメインリポジトリは、"Portage tree"と通称されています。 ちなみにPortageツリーは、現在は GitHub にもミラーリングされていますので気軽に参照可能です(昔はGitを使用していませんでした(CVSでした)し、ましてやGitHubミラーなんてありませんでした)。 ( https://github.com/gentoo-mirror/gentoo )

そのPortageツリー、その内部のパッケージの実体についての話です。

ルート

たくさんのディレクトリがありますが、 現在のところ、 間にハイフンの入っているディレクトリと、virtualというディレクトリの名称は、パッケージのカテゴリの名称と同じです。 例えば、 x11-libs という名称のディレクトリがありますが、これは X11(つまり多くはX.Org)と関係のあるライブラリに関するパッケージの入っているディレクトリ、という意味です。このように、〇〇の✕✕という形式でカテゴリ名が決まっています。 またvirtualというカテゴリは、ソフトウェアの実体は無いがdependencyの解決のためなどに必要なのでつくられたパッケージが入っています。

カテゴリ以外のディレクトリには、

  • eclass
  • licenses
    • 各ソフトウェアのライセンス条項の本文を格納
  • metadata
    • リポジトリの情報を検索するためのキャッシュや、リポジトリのデータを定義するためのメタ情報や、ユーザに配信するニュースなどを格納
  • profiles
    • USEフラグやインストールのマスク(禁止)などの各種設定を格納
  • scripts
    • 中身を見ての通り、bootstrap のスクリプトが保管されている

という状況になっていますが、今回はパッケージの構造についての話をしますので、詳細は措いておきます。

カテゴリ内

さて、カテゴリのディレクトリの中には、カテゴリの定義を示したファイル(metadata.xml)も入っていますが、その他は、パッケージ名がそのままディレクトリ名になっています。

試しに x11-libs の中を覗くと( https://github.com/gentoo-mirror/gentoo/tree/master/x11-libs )、たくさんのパッケージがありますね。

そこで例えば、(X.Org環境を使用しているかなりの人が知っているでしょう) gksu というパッケージを覗いてみましょう。( https://github.com/gentoo-mirror/gentoo/tree/master/x11-libs/gksu )

Manifest という名称のファイルは、そのソフトウェアの source tarball など、取得するであろうファイルのハッシュ値が記載されています。 ( https://github.com/gentoo-mirror/gentoo/blob/master/x11-libs/gksu/Manifest )
この情報で、ダウンロードしてきたファイルが(壊れていたり改竄されたりしていない)真正なものか、パッケージマネージャが自動的に確認してくれるわけです。

また、パッケージ内に置かれている metadata.xml は、パッケージの情報を定義したメタデータを書いた XML ファイルです。( https://github.com/gentoo-mirror/gentoo/blob/master/x11-libs/gksu/metadata.xml )
具体的には、そのソフトウェア(upstream)の(長い)説明だとか、upstream の作者やバグリポート先だとか、パッケージのメンテナが誰か(もしくはどの組織か)だとか、使える USE フラグに関する説明だとかが書かれます。

files というディレクトリには、パッチファイルや、その他必要な配布ファイルを格納します。( https://github.com/gentoo-mirror/gentoo/tree/master/x11-libs/gksu/files )

そして、.ebulidで終わるファイルが、パッケージのインストールなどをするためのスクリプトファイルで、つまりパッケージの本体です。

この .ebulid のファイル名ですが、 パッケージ名-バージョン-リビジョン.ebuild という形式になっています。 この時気をつけなければならないのは、「バージョン」とはupstreamの(ソフトウェア自体の)バージョンで、「リビジョン」とはebuildファイル自体のリビジョンだということです。 ebuildファイル自体も更新されるわけですから、リビジョン情報が必要になることもあるわけですね。 なお、リビジョンがまだ無ければ、付かないままのファイル名になります。

gksu-2.0.2-r1.ebuild なら、 gksu というパッケージ名で、バージョンは 2.0.2 です。 ebuild ファイルは r1 にリビジョンアップされています。

ちなみに、このようにファイル名が変えられて追加・削除が繰り返されていくという仕様ですので実は、Git のようなバージョン管理システムには不向きな一面があります。(一般的なソフトウェアのバージョン管理は、ファイル名はそのままで、ソースコードの中身を書き換えますよね?)

ebuild 内の変数

Portageなどのパッケージマネージャは、この ebuild スクリプトファイルを読み込んで処理をするわけです。

ebuild ファイルの中身をみると、冒頭にいくつものvariable(いわゆる「変数」)が定義されています。 よく知らなくても意味がおよそ想像のつく名称の変数もありますね。 例えば DESCRIPTIONHOMEPAGESRC_URILICENSEDEPEND がそうですね。

KEYWORDSアーキテクチャごとの動作確認状況を定義していますし、 そして IUSE で USE フラグが定義されていますね。

ただ今回は、これらの変数を逐一列挙していくことは省きます。

自動的に代入される変数

またそれ以外にも、変数が自動的に定義されて ebuild ファイルが処理されます。

それが例えば

  • PN
    • パッケージ名
  • PV
    • パッケージのバージョン
  • CATEGORY
    • パッケージの所属するカテゴリ
  • FILESDIR
    • そのパッケージの files ディレクトリのパス

こうした情報はそもそも、ディレクトリ構造が決まっているから読み取れるのですよね。だから自動的に定義することが可能なわけですね。

こうした変数については Gentoo Development Guide: Variables に書いてあります。 各変数とその詳細はこれを読んでください。 ちなみにこの文書は、 app-doc/devmanual をインストールすれば、ローカルでも読めます。

パッケージ名の構造

というわけで、Gentoo ではパッケージは、カテゴリ/パッケージ名 の形式で特定するわけなのです。 これで、app-doc/devmanual とか x11-libs/gksu とか言われても解りますよね。

ちなみに、カテゴリ名を明示しないでパッケージ名だけを言ったときには、異なるカテゴリにまた同名のパッケージがあるということもあります。 そのため、パッケージマネージャなどでコマンドを実行する際にも、カテゴリ名を付けて指定しないといけない場面もしばしばあります。

例えば dev-haskell のカテゴリには、その Haskell ライブラリが利用する元のソフトウェア名がそのままパッケージ名になっていることがよくあります。 一例を挙げると、 curl というパッケージも、 dev-haskellnet-misc の2つのカテゴリに同名があります。dev-haskell/curl のほうは、net-misc/curl のライブラリを利用するための Haskell ライブラリです。 net-misc/curl をインストールしたいときでも例えば emerge curl だけでは、 emerge にとってはどちらの curl か判りません。


この投稿は、

qiita.com

7日めの記事です。 ファッションセンターしまむらに行ったらセールをやっていて、かわいい袢纏があり買ってきたので、それを着て書きました。