Handbook:Parts/Working/Portage/ja

Portage へようこそ
portageはソフトウェア管理における、Gentooの最も特筆すべき技術革新のひとつです. その高い柔軟性と膨大な量の機能により、Linuxで利用可能な最高のソフトウェア管理ツールであると見なされることもしばしばです.

portageはすべてPythonとBashで書かれています. どちらもスクリプト言語なので、ユーザはそのすべてを見ることができます.

ほとんどのユーザはというツールを挟んでPortageを利用することになるでしょう. この章はemergeのmanページにある情報をすべて記述することを目的とはしていません. emergeのオプションの完全な概要については、manページを参照してください：

Ebuild
Gentooのドキュメントがパッケージという言葉を使うとき、それはGentooリポジトリ上でGentooユーザが利用可能なソフトウェア名のことを指します. Gentooリポジトリとは、Portageがソフトウェアを整備（インストール、検索、クエリ、など）するために必要なすべての情報を含む、ebuildというファイルの集合体です. これらのebuildはデフォルトではにあります.

ユーザがPortageを使ってソフトウェア名に関してなんらかの操作を行うとき、Portageはシステム上のebuildをベースとして使います. なので、Portageが新しいソフトウェアやセキュリティアップデートを知るために、定期的にシステム上のebuildを更新することが大切です.

Gentooリポジトリの更新
Gentooリポジトリは通常、高速な増分ファイル転送ユーティリティであるを使って更新されます. コマンドはのフロントエンドを提供しているので、更新はとても簡単です：

一部のファイアウォールは がミラーに接続するのを制限してしまいます. この場合は毎日生成されるスナップショットを使ってGentooリポジトリを更新しましょう. ツールは最新のスナップショットを自動的に取得し、システムにインストールします.

システム管理者にとっては、GentooリリースエンジニアリングGPG鍵によって署名されたスナップショットだけを取得したい時にも が役に立つことでしょう. これに関する詳細は "Portageの機能" 記事の検証済みのGentooリポジトリスナップショットで読むことができます.

ソフトウェアの検索
Gentooリポジトリでソフトウェアを探す方法は色々あります. そのひとつは 自身を使う方法です. デフォルトでは は与えた検索キーワードをタイトル (の一部または全体) に含むパッケージの名前を出力します.

例えば、名前に "pdf" を含むパッケージを探してみましょう:

パッケージの説明文も検索対象にするには、 (か  ) オプションを使います:

この出力には様々な情報が含まれています. 各項目にはわかりやすいラベルがついているので、ここでその意味を説明する必要はないですね:

ソフトウェアのインストール
ソフトウェアの名前がわかったら、インストールは コマンドを実行するだけです. 例えば gnumeric をインストールするにはこうします:

多くのアプリケーションは互いに依存しあっているので、あるソフトウェアパッケージのインストールにはいくつかの依存パッケージのインストールを伴う場合があります. でも大丈夫、Portageがちゃんと依存関係を見ています. Portageがインストールしようとしているものを確認するには、 オプションを付けます. 例えば:

パッケージのインストールの過程で、Portageは(必要なら)ソースコードをインターネット上からダウンロードし、デフォルトでは に保存します. インストールせずにダウンロードだけさせたい時は、 オプションを emerge コマンドにつけます.

インストールしたパッケージのドキュメントを探す
多くのパッケージにはドキュメントが付属しています. そしてドキュメントをインストールするかどうかを選択する  USEフラグが用意されていることがあります. パッケージで  USEフラグが使われるかどうかは、 で調べることができます:

ドキュメントはそれをインストールしたいパッケージにのみインストールしたいでしょうから、 USEフラグは  でパッケージごとに指定することをお勧めします. 詳しくは USE フラグの節 をご覧ください.

パッケージをインストールすると、ドキュメントはたいてい 内のパッケージ名のディレクトリで見つけることができます:

ドキュメントファイルを一覧表示するもっと確実な方法は、 の  オプションを使うことです. は Portage のデータベースを検索するために使われるもので、 パッケージの一部としてインストールされます:

オプションを他のルールとともに使えば、他の種類のファイルのインストール場所を見るためにも使えます. 他の機能については の man ページで確認できます:.

ソフトウェアの削除
ソフトウェアをシステムから削除するには、 を使います. これはそのパッケージによってインストールされたすべてのファイルを削除するようPortageに指示しますが、ひとつ例外があります. アプリケーションの設定ファイルのうち、ユーザーが変更したものは削除されません. これは後で同じパッケージをインストールしなおした時に再設定する手間を省くためです.

パッケージがシステムから削除されても、そのパッケージが必要としたために自動的にインストールしたパッケージはまだ残っています. このような削除可能なパッケージを洗い出すには、emergeの  機能を使いますが、これは後ほど説明します.

システムの更新
システムをきれいに保つため (そしてもちろん最新のセキュリティアップデートを適用するため) には、日常的にシステムを更新する必要があります. PortageはGentooリポジトリに入っているebuildしか確認しませんから、最初にすることはリポジトリの更新です. Gentooリポジトリが更新できたら、 でシステムを更新することができます. 次の例では、Portageが更新したいパッケージを表示してユーザーの確認を待つよう、 オプションも指定しています.

Portageはインストール済みのアプリケーションに新しいバージョンがあるかどうかを調べます. しかし、これは明示的にインストールされたアプリケーション ( に記載されているもの) のみが対象であって、それらの依存パッケージはチェックされません. それら依存パッケージも更新するには、 オプションを指定します:

これでも全てのパッケージが対象というわけではありません. 中にはパッケージのコンパイルやビルドに必要なだけで、パッケージのインストール後には不要になる依存パッケージがあります. Portageはこれを "ビルド時依存" と呼びます. これも更新に含めるには  を付けます:

セキュリティアップデートは明示的にインストールしていない (他のプログラムが依存している) パッケージにも配信されることがあるので、時々はこのコマンドを実行するとよいでしょう.

システムのUSE設定を変更したときは、 も指定することをお勧めします. こうすると、その変更に新しいパッケージのインストールや既存パッケージの再コンパイルが必要でないかどうか、Portageが調べてくれます.

メタパッケージ
Gentooリポジトリの中には、それ自体は中身を持たず、パッケージの集合をインストールするためだけに用意されたパッケージが存在します. 例えば パッケージは、Plasma関連の様々なパッケージを依存に持つことで、KDE Plasmaデスクトップをインストールします.

このようなパッケージをシステムから削除しようと を実行しても、その依存パッケージはシステムに残っているため、あまり効果がありません.

Portageには、孤独な依存関係を削除する機能も備えています. しかし、ソフトウェアの可用性は動的依存のため、まずシステム全体を完全にアップデートすることが重要です. これにはUSEフラグの変更が適用された新しい変更も含みます. これの後、を実行し、孤独な依存関係を削除することが出来ます. これが完了したら、今削除されたソフトウェアと動的にリンクしていたが、もはやそのソフトウェアを必要としないアプリケーションの再ビルドが必要かもしれません. 尤も、最近このサポートはPortageに追加されましたが.

以上のことのすべては3コマンドで行われます:

は パッケージによって提供されているので、忘れずに emerge しておいてください:

ライセンス
Portage バージョン 2.1.7 以降、ライセンスを基準にソフトウェアのインストールを許可または拒否することができます. ツリー内のすべてのパッケージは LICENSE エントリを含みます. を実行するとパッケージのライセンスが表示されます.

Portage はデフォルトでは、フリーソフトウェア財団、Open Source Initiativeによって明示的に承認されたライセンス、あるいは自由ソフトウェアの定義に従っているライセンスを許可します.

許可するライセンスを制限する変数は ACCEPT_LICENSE と呼ばれ、 ファイル内で設定できます. 次の例はデフォルト値を示しています:

この設定の下では、自由ソフトウェアライセンスあるいは自由な文書ライセンスが設定されているパッケージがインストール可能となります. フリーではないソフトウェアはインストールできなくなります.

ACCEPT_LICENSE は 内でグローバルに設定することもできますし、 ファイル内でパッケージ毎に定義することもできます.

たとえば、 ライセンスを パッケージのために許可するには、 に次の内容を追加してください:

これにより パッケージのインストールは許可しますが、同じライセンスを持っていたとしても  パッケージのインストールは禁止されます.

ACCEPT_LICENSE 変数内で定義されるライセンスグループは  記号で始まります. ありうる（かつてPortageのデフォルトだった）設定は、使用許諾契約書を読み同意する必要があるEnd User License Agreements（使用許諾契約、EULA）を除いてすべてのライセンスを受諾する設定です. これを実現するには、次のように、現在許可されているすべてのライセンスを受諾し（ を使います）、その後 EULA グループ内のライセンスのみを受諾取り消ししてください:

この設定は、フリーではないソフトウェアや文書も受諾する事に注意してください.

用語について
前述の通り、Portage は非常に強力で、他のソフトウェア管理ツールにはない多くの機能をサポートしています. これを理解するために、Portage のいくつかの観点について、深追いしすぎない程度に説明していきます.

Portage を使うと、ひとつのパッケージの異なる複数のバージョンをシステム上に共存させることができます. 他のディストリビューションはパッケージ名をバージョンにちなんで命名する（例えば freetype と freetype2 のように）ことが多いですが、Portage はスロット（SLOT）という技術を使用します. 各 ebuild はそのバージョンに応じてひとつのスロットを宣言します. 異なるスロットを持つ ebuild は同一システム上に共存できます. 例えば、freetype パッケージの ebuild には SLOT="1" のものと SLOT="2" のものが存在します.

同じ機能を提供するものの、実装の異なる複数のパッケージというものもあります. 例えば、metalogd、sysklogd、syslog-ng はすべてシステムロガーです. "システムロガー"の利用を前提とするアプリケーションは、例えば、metalogd に依存するわけにはいきません. 他のシステムロガーも同じくらい良い選択肢でありうるからです. そこで Portage は仮想（virtual）パッケージというものを許容しています. 各システムロガーは、virtual カテゴリの logger 仮想パッケージの"排他的な"依存パッケージとしてリストされていて、アプリケーションは パッケージに依存すればいいようになっています. このパッケージをインストールすると、すでにロギングパッケージがインストールされていない限り（この場合は仮想パッケージの依存が解決していることになります）、言及されている最初のロギングパッケージがインストールされます.

Gentoo リポジトリのソフトウェアは異なるブランチに所属できます. デフォルトでは、システムは Gentoo が安定している（stable）と考えるパッケージだけが許容されます. ほとんどの新しいソフトウェアタイトルは、コミットされた時点ではテスト中（testing）ブランチに追加されます. stable としてマークする前にまだテストが必要だということです. こうしたソフトウェアの ebuild は Gentoo リポジトリ内に存在していますが、stable ブランチに置かれるまで Portage はこれらをアップデートしません.

一部のアーキテクチャでのみ利用可能なソフトウェアもあります. 他のアーキテクチャでは動作しない、テストが不十分、そのソフトウェアを Gentoo リポジトリにコミットした開発者が異なるアーキテクチャ上で動作するか確認できない、などの理由がありえます.

Each Gentoo installation also adheres to a certain profile which contains, amongst other information, the list of packages that are required for a system to function normally.

ブロックされたパッケージ
ebuild には、それが依存するパッケージについて Portage に伝えるためのフィールドが含まれています. DEPEND 変数で宣言されるビルド時依存と、 RDEPEND 変数で宣言される実行時依存です. これらの依存パッケージのうち一つが明示的にパッケージや virtual を共存できないとマークしているとき、ブロックが発生します.

最近のバージョンの Portage はささいなブロックであればユーザの手助けなしで対処できますが、ブロックを手動で解決することが必要になる場合もあります.

ユーザはブロックを解決するために、そのパッケージをインストールしないか、コンフリクトしているパッケージを先に unmerge するかを選ぶことができます. 上の例でいえば、postfix のインストールをやめるか、先に ssmtp を取り除くか選べます.

特定のアトムを対象にしたブロックもあります. 例えば  のようなものです. この場合は、ブロックしているパッケージをより新しいバージョンにアップデートすることで、ブロックを取り除くことができるかもしれません.

まだインストールされておらず、今からインストールしようとしている 2 つのパッケージがお互いにブロックしあっている、ということもありえます. このレアケースでは、なぜその両方をインストールする必要があるのか調査してください. ほとんどの場合は片方だけで十分です. もしそうでなければ、Gentoo のバグトラッキングシステムにバグを報告してください.

マスクされたパッケージ
現在のシステムで利用可能でないパッケージをインストールしようとしたときに、このマスキングエラーが発生します. ユーザはシステムで利用可能な別のアプリケーションのインストールを試みるか、パッケージが利用可能としてマークされるまで待つべきです. パッケージがマスクされているのには必ず理由が存在します:

USEフラグの変更が必要
がセットされていないと、次のようなエラーメッセージも表示されるかもしれません:

このような警告やエラーは、インストールしようとしているパッケージが他のパッケージに単に依存しているだけでなく、そのパッケージが特定の USE フラグ（またはその集合）とともにビルドされていることも要求するときに発生します. 上の例では、パッケージ app-text/feelings が USE="test" とともにビルドされていることを要求していますが、この USE フラグがシステム上でセットされていない状態です.

これを解決するには、要求された USE フラグを 内でグローバル USE フラグに追加するか、 内で特定のパッケージに対してセットしてください.

依存パッケージが見つからない
インストールしようとしているアプリケーションは、システムで利用可能でない他のパッケージに依存しています. この問題が既知のものかどうか Bugzilla を確認し、もしそうでなければ報告してくれると助かります. システムが複数のブランチを混ぜる設定になっていなければ、この事態は発生すべきではなく、バグです.

あいまいなebuild名
インストールすることが選択されたアプリケーションの名前が複数のパッケージに対応しています. これを解決するには、カテゴリ名も付け加えてください. Portage は何から選べばいいか、マッチしたものを教えてくれるでしょう.

循環依存
インストールする 2 個（またはそれ以上）のパッケージがお互いに依存しているため、インストールできません. これはほとんどの場合 Gentoo リポジトリ内のパッケージのどれかにバグがある状態です. 時間をおいて再 sync してからもう一度試してください. Bugzilla をチェックしてこの問題が既知のものであるか確認し、そうでなければ報告することも有益でしょう.

フェッチ失敗
Portage が与えられたアプリケーションのソースをダウンロードできなかったため、他のアプリケーションのインストール（するものがあれば）を続行しようとしています. この失敗は、正しく同期されていないミラーのために、あるいは ebuild が正しくないダウンロード先を指しているために起こることがあります. ソースを置いているサーバが何らかの理由でダウンしていることも考えられます.

1 時間ほど時間をおいて再試行し、問題が継続しているか確認してください.

システムプロファイルによる保護
ユーザがシステムのコアパッケージの一部をなすパッケージを削除しようとしました. パッケージはプロファイルによって必須として記載されているため、システムから削除するべきではありません.

ダイジェスト検証失敗
これは Gentoo リポジトリに何かおかしなことが起きていることを示しています - 多くの場合は Gentoo ebuild リポジトリに ebuild をコミットするときのミスによるものです.

ダイジェスト検証に失敗しても、自分でパッケージのダイジェストを再計算しようとしないでください. を実行しても問題の解決にはならないどころか、より状況を悪化させるでしょう.

かわりに、リポジトリが大人しくなるまで 1、2 時間ほど待ってください. このエラーはすぐに気づかれるでしょうが、修正が rsync ミラーたちに浸透していくには少々時間がかかることがあります. Bugzilla をチェックしてすでに誰かが問題を報告しているか確認するか、 (IRC) で聞いてください. まだであれば、遠慮なく壊れた ebuild のためにバグを提出してください.

バグが修正されたら、Gentoo ebuild リポジトリを再同期して修正されたダイジェストを引っ張ってきてください.