|
PortageはGentooのソフトウェア管理における最も注目すべき革新と言えるでしょう。 その高い柔軟性と非常に多くの機能により、Linuxで利用できる最高のソフトウェア管理ツールとされることがよくあります。 Portageは全てPythonとBashによって書かれており、 両方ともスクリプト言語であるため、ユーザーにとって全体的に見通しのよいものになっています。 ほとんどのユーザーがemergeツールを通してPortageを利用しています。 この章はemergeのmanページで得られる情報の複製を意図したものではありません。 emergeのオプションについての完全な概要を得るためには、manページを調べてください。
パッケージについて話す場合、たいていは、GentooユーザーがPortageツリーを通して利用可能なソフトウェア名を意味しています。 Portageツリーはebuildという、Portageがソフトウェアを維持管理する(インストール、検索など)ために必要な全ての情報を含んだファイルのコレクションです。 デフォルトでは、これらebuildは/usr/portageに置かれています。 Portageにソフトウェア名に関して、何か実行するよう指示するときはいつでも、システムにあるebuildがベースに使われます。 そのため、システムのebuildを定期的に更新することが重要です。 そうすれば、新しいソフトウェアやセキュリティアップデートなどを利用することができます。 Portageツリーは通常rsyncという高速差分ファイル転送ユーティリティで更新されます。 更新はrsyncのフロントエンドを提供するemergeコマンドを使うという、とても簡単なものです。
もしファイアーウォールの制限によりrsyncが実行できないときには、毎日作成されるPortageツリーのスナップショットを利用することによってPortageを更新することができます。 emerge-webrsyncツールは自動的に最新のスナップショットを取得し、システムにインストールしてくれます。
emerge-webrsyncを使うとGentooリリースエンジニアリングチームのGPG鍵でサインされているPortageツリーのスナップショットでツリーを更新できるという利点もあります。 詳しくは(Portageの機能)のセクションの(検証済みのPortageツリースナップショットを取得する)を参照してください。 Portageツリーからソフトウェア名を検索するには、emergeに内蔵された検索能力を利用することができます。 デフォルトでは、emerge --searchは検索単語に(完全にもしくは部分的に)一致したパッケージ名を返します。 例えば、"pdf"を名前にふくむパッケージを検索するにはこうします。
もしパッケージの詳細な説明を検索したいのなら--searchdesc(もしくは -S)引数を使うことができます。
出力を見れば、それがたくさんの情報を提供していることに気付くでしょう。 その内容が意味するところがわかるように、各フィールドにははっきりとラベル付けがされています。
好みのソフトウェアを見つけたら、emergeで簡単にインストールすることができます。ただパッケージの名前を追加するだけです。 例えば、gnumericをインストールするにはこうします。
たくさんのアプリケーションがお互いに依存し合っているため、あるソフトウェアをインストールしようとすると、 結果的にいくつかの依存関係もインストールすることになるでしょう。 ご心配なく、Portageは依存関係をうまく扱ってくれます。 もしパッケージをインストールするときにPortageが何をインストールしようとしているか確かめたい場合には、 --pretend引数を追加します。例えばこのようにします。
Portageにパッケージをインストールするよう要求したときは、 必要なソースコードをインターネットからダウンロードし、 デフォルトでは/usr/portage/distfilesに保存します。 この後、ソースコードが展開され、コンパイルが実行されて、パッケージがインストールされます。 Portageにソースをダウンロードするだけでインストールを行って欲しくないときには、 emergeコマンドに--fetchonlyコマンドを追加します。
多くのパッケージはドキュメントと共にインストールされます。 docUSEフラグでパッケージのドキュメントをインストールするかしないかが決まる場合もあります。 現在のdocUSEフラグを確認するにはemerge -vp <package name>コマンドを使用します。
/etc/portage/package.useによってパッケージごとにdocUSEフラグを有効にする事をおすすめします。 そうすれば、興味のあるパッケージの分だけドキュメントを取得できるようになります。 このフラグをシステム全体で有効にしてしまうと、循環依存の問題を起こす原因となることが知られています。 詳しくは、(USEフラグ)の章を読んでください。 パッケージがインストールされると、ドキュメントは一般的には/usr/share/docディレクトリの下のパッケージ名のディレクトリの中に置かれます。 app-portage/gentoolkitパッケージ（日本語訳）の一部であるequeryツールを利用すると、全てのインストールされたファイルの一覧を表示できます。
システムからパッケージを削除したいときは、emerge --unmergeを利用します。 これはPortageにパッケージによってインストールされた全てのファイルを削除するよう命令します。 ただし、インストール後に変更されたアプリケーションの設定ファイルは削除されません。 設定ファイルを残しておくことで、再びインストールすれば、パッケージは適切に動作します。 しかし、大きな警告があります:Portageは削除したいパッケージが他のパッケージから必要とされているかを確認しません。 しかし、少なくともunmergeするとシステムを破壊する様な重要なパッケージを削除するときにはPortageに警告されます。
システムからパッケージを削除するときには、インストール時に依存関係により自動的にインストールされたソフトウェアは残されます。 依存関係でインストールされたソフトウェアから削除可能なものを全て検索するには、emergeの--depclean引数を利用します。 これについては後で話します。 システムを完全な形に保つ(最新のセキュリティアップデートをインストールする様に言われない為にも)には、システムを定期的に更新する必要があります。 Portageはツリーの中のebuildsのみ確認するので、最初にPortageツリーを更新しなければなりません。 Portageツリーが更新されたら、emerge --update worldでシステムを更新できます。 次の例では--ask引数を使用しています。 これは、更新するパッケージの一覧をPortageに表示させ、続行するかを尋ねます。
Portageはインストールされているアプリケーションの新しいバージョンを検索します。 しかし、これは明示的にインストールされたものしか確かめません（そうしたアプリケーションは/var/lib/portage/worldにリストされています）。 つまり、それらの依存関係は確認しないということです。 明示的にインストールされたパッケージの依存も更新したいときには--deep引数を与えてやります。
これでも全てのパッケージが更新されるわけではありません。 システムにインストールされているパッケージの中にはコンパイルとビルドの間には必要ではあるものの、 インストールが終わってしまえばもう必要ないようなパッケージもあります。 Portageでは、そのようなパッケージをbuild dependencies (ビルド依存)と呼んでいます。 これを更新に含めるには--with-bdeps=yを追加します。
明示的にインストールしていない（だが他のプログラムの依存によりインストールされた）パッケージのセキュリティアップデートがあるかもしれないので、このコマンドを時々実行することが推奨されています。 もし最近(USEフラグ)を変更したのなら、--newuseを追加したくなるでしょう。 そうするとPortageは新しいパッケージのインストールや既にインストールしたパッケージの再コンパイルが必要かを確認します。
Portageツリーのいくつかのパッケージには、それ自身は何のファイルもインストールしませんが、複数のパッケージをインストールするのに利用されるものがあります。 例えば、kde-metaパッケージは、依存関係にある様々なKDE関連のパッケージを制御することで、システムに完全なKDE環境をインストールします。 このようなパッケージをシステムから削除したいときには、emerge --unmergeをパッケージに対して実行しても依存関係が残ってしまうのでたいした効果は得られないでしょう。 Portageは残された依存関係を削除する機能性を持っていますが、動的に依存関係を変更するソフトウェアが存在するので、 USEフラグに変更を加えたときも含めてまずシステムを完全に更新する必要があります。 その後残された依存関係を削除するためにemerge --depcleanを実行してください。 これが完了したら、今削除されたソフトウェアを動的にリンクしているが、もはやそれを必要としないアプリケーションを再ビルドします。 これら全ては以下の３つのコマンドで処理できます。
revdep-rebuildはgentoolkitによって提供されます;まず最初にemergeすることを忘れないでください。
Portage バージョン2.1.7から、ソフトウェアのライセンスをもとにして、ソフトウェアのインストール可否を制御できます。 Portageツリーにある全てのパッケージには、ebuildにLICENSE項目が含まれています。 emerge --search packagenameを実行すれば、パッケージのライセンスがわかります。 デフォルトでは、使用許諾契約書(EULA)に同意しなければならないものを除いて、Portageは全てのライセンスを許可します。 許可するライセンスを制御するのは、ACCEPT_LICENSEです。これは、/etc/make.confのなかで設定されます。
この設定により、インストール中に使用許諾契約書に同意する行為が発生するようなパッケージは、インストールされず、 使用許諾契約書がないパッケージがインストールされます。 ACCEPT_LICENSEはシステム全体では/etc/make.confで設定可能です。 また、パッケージごとに/etc/portage/package.licenseでも設定可能です。 たとえば、app-crypt/truecryptに対して、truecrypt-2.7ライセンスを許可する場合、 次の内容を/etc/portage/package.licenseに追加してください。
これによって、truecrypt-2.7ライセンスでのインストールは許可されますが、truecrypt-2.8ライセンスでのインストールは許可されません。
ACCEPT_LICENSEで定義されたライセンスグループは、@記号が先頭につきます。 次の例ではシステム全体で、GPL互換ライセンスグループと他のライセンスグループと個別ライセンスをいくつか許可しています。
もし、フリーなソフトウエアとフリーなドキュメントだけのシステムにしたい場合は、次のようにすればよいでしょう。
この場合の"フリー"とは、ほぼFSF と OSIで定義されたものです。 これらの定義に合致しないライセンスを持つパッケージはインストールされません。 SLOT、Virtual、ブランチ、アーキテクチャ、そしてプロファイルについて 既に述べたように、Portageはとても強力で他のソフトウェア管理ツールに無い多くの機能をサポートしています。 このことを理解するために、あまり細かくなり過ぎるのを避けて、もう少しPortageの特徴について説明します。 Portageでは、同一のパッケージの異なるバージョンをシステム上に共存させることができます。 他のディストリビューションが(freetypeとfreetype2の様に)それらの名前にバージョンを付けているのに対し、 PortageはSLOTと呼ばれる技術を使っています。 ebuildはそのバージョンごとにSLOTを宣言します。SLOTが異なるebuildはシステム上で共存できます。 例えば、freetypeパッケージはSLOT="1"とSLOT="2"のebuildを持っています。 同一の機能を提供する実装の異なるパッケージもまた存在します。 例えば、metalogd、sysklogd、syslog-ngは全てシステムロガーです。 「システムロガー」の機能を必要とするアプリケーションは、例えばmetalogdに依存することはできません。他のシステムロガーも同様に問題のない選択だからです。 Portageはvirtualsを考慮に入れます:他のアプリケーションがvirtual/syslogに依存できるように、それぞれのシステムロガーはvirtual/syslogを提供します。 Portageツリーのソフトウェアは異なったブランチに所属することができます。 デフォルトではシステムはGentooがstableだと思うもののみ受け付けます。 ほとんどのコミットされた新しいソフトウェア名は、stableにされる前にもっとテストが必要だという意味のテストブランチに追加されます。 これらのソフトウェアのebuildをPortageツリーで見かけても、Portageはstableブランチに置かれるまでは更新しようとしないでしょう。 いくつかのソフトウェアは特定のアーキテクチャでのみ利用可能な場合があります。 すなわちそのソフトウェアは他のアーキテクチャでは動作しないか、もっとテストが必要か、 Portageツリーにソフトウェアをコミットした開発者が別のアーキテクチャで動作するかどうか確認できないかです。 各々のGentooのインストールはあるプロファイルに従っています。 プロファイルには、システムが正常に動作するために必要なパッケージのリストなどが含まれています。
ebuildは、Portageにその依存関係についての情報を指示する特別なフィールドを含んでいます。 依存関係には2つの種類があります: DEPENDによって宣言されたビルド依存と、RDEPENDによって宣言された実行時依存です。 これらの依存関係で明示的に互換性のないパッケージまたはvirtualが指定されている場合、インストールがブロックされます。 Portageの最近のバージョンでは、些細なブロックについてはユーザーへの注意を促すことなく対処することができますが、 場合によっては、次に説明する方法でユーザー自身で解決しなければなりません。 ブロックを解決するには、パッケージのインストールを行わないか、衝突しているパッケージを先にunmergeするかのどちらかを選べます。 上記の例では、postfixのインストールを諦めるか、先にssmtpを削除するかのどちらかです。 <media-video/mplayer-1.0_rc1-r2.のように特定のパッケージ識別子（atom）を伴いブロックされていることがあるかもしれません。 この場合、ブロックしているパッケージをより新しいバージョンに更新すれば、ブロックを取り除くことができるかもしれません。 2つのパッケージがインストールしようとして、お互いをブロックし合っていることもあります。 このまれな場合には、何故それらをインストールする必要があるのかを調べてみてください。 ほとんどの場合、1つのパッケージのみで事足ります。 そうでなければ、Gentooのバグトラックシステムにバグを報告してください。
システムで利用できないパッケージをインストールしようとしたときに、このマスクエラーを受け取るでしょう。 システムで利用できる他のアプリケーションのインストールを試すか、パッケージが利用可能になるまで待ちましょう。 パッケージがマスクされているのにはいつも理由があります。
--autounmaskをつけていなければエラーメッセージは次のようになっているでしょう。
こういった警告やエラーは、ただ単純に他のパッケージに依存しているだけでなく、 そのパッケージが特定のUSEフラグ(や、複数のUSEフラグの組みあわせ)でビルドされていることを必要とするパッケージをインストールする時に起こります。 上の例ではapp-text/feelingsはUSE="test"でビルドされていなければいけませんが、 このUSEフラグはシステムで設定されていません。 これを解決するには/etc/make.confでグローバルUSEフラグに追加するか、 または/etc/portage/package.useでパッケージごとのUSEフラグを設定してください。
インストールしようとしているアプリケーションはシステムで利用できない他のパッケージに依存しています。 bugzillaに既に報告されているか確認して、まだであれば報告してください。 ブランチを混ぜていない限りこれが起こることはありませんので、それはバグであると言えます。
インストールしようとしているアプリケーション名が2つ以上と一致しています。 正しいカテゴリー名も追加する必要があります。 Portageが(カテゴリー名をふくんだ)パッケージの候補を出力してくれます。
２つ(もしくはそれ以上)のインストールしたいパッケージがお互いに依存し合っているためにインストールすることができません。 これはほとんどはPortageツリーのバグです。 bugzillaに既に報告されているか確認して、まだであれば報告してください。
Portageがアプリケーションのソースのダウンロードに失敗し、(可能であれば)他のアプリケーションのインストールを続けようとしています。 この失敗はミラーが正しく同期されていないか、ebuildが正しくない場所を示しているからかもしれません。 ソースを置いているサーバーが何らかの理由でダウンしているのかもしれません。 一時間程度空けて、もう一度確認してみましょう。
あなたはシステムのコアの一部であるパッケージを削除しようとしました。 しかし、プロファイルで必須であるとされているので、システムから削除するべきではありません。 ときどき、あるパッケージをemergeしようとして、次のようなメッセージと共に失敗することがあるかもしれません。
これはPortageツリーにどこかおかしい所がある兆候です。 よく、開発者がパッケージをツリーにコミットするとき失敗したことが原因で起こります。 ダイジェストの検証に失敗するとき、そのパッケージをあなた自身でダイジェストを再度作成しようとしてはいけません。 この問題はebuild foo manifestでは修正されない上に、ほぼ間違いなく悪化します。 かわりに、1時間か2時間ツリーが安定するのを待っていてください。 おそらくエラーはすぐに検知されると思いますが、修正がPortageツリーに流れるのに少し時間がかかります。 待っている間、Bugzillaをチェックし、誰かがこの問題をすでに報告しているか調べてください。 もし報告している人がいなければ、壊れているパッケージのバグ報告をしてください。 この問題が修正されたら、ダイジェストが修正されたツリーを再び同期しましょう。
|
|