ハンドブック:SPARC/ワーキング/Portage
Portage へようこそ
portageはソフトウェア管理における、Gentooの最も特筆すべき技術革新のひとつです。その高い柔軟性と膨大な量の機能により、Linuxで利用可能な最高のソフトウェア管理ツールであると見なされることもしばしばです。
portageはすべてPythonとBashで書かれています。どちらもスクリプト言語なので、ユーザはそのすべてを見ることができます。
ほとんどのユーザはemergeというツールを挟んでPortageを利用することになるでしょう。この章はemergeのmanページにある情報をすべて記述することを目的とはしていません。emergeのオプションの完全な概要については、manページを参照してください：
user $man emergeGentoo リポジトリ
Ebuild
Gentooのドキュメントがパッケージという言葉を使うとき、それはGentooリポジトリ上でGentooユーザが利用可能なソフトウェア名のことを指します。Gentooリポジトリとは、Portageがソフトウェアを整備（インストール、検索、クエリ、など）するために必要なすべての情報を含む、ebuildというファイルの集合体です。これらのebuildはデフォルトでは/var/db/repos/gentooにあります。
ユーザがPortageを使ってソフトウェア名に関してなんらかの操作を行うとき、Portageはシステム上のebuildをベースとして使います。なので、Portageが新しいソフトウェアやセキュリティアップデートを知るために、定期的にシステム上のebuildを更新することが大切です。
Gentoo リポジトリの更新
Gentooリポジトリは通常、高速な増分ファイル転送ユーティリティであるrsyncを使って更新されます。emergeコマンドはrsyncのフロントエンドを提供しているので、更新はとても簡単です：
root #emerge --sync一部のファイアウォールは rsync がミラーに接続するのを制限してしまいます。この場合は毎日生成されるスナップショットを使って Gentoo リポジトリを更新することができます。emerge-webrsync ツールは最新のスナップショットを自動的に取得し、システムにインストールします。
root #emerge-webrsyncソフトウェアを保守する
ソフトウェアの検索
Gentooリポジトリでソフトウェアを探す方法は色々あります。そのひとつは emerge 自身を使う方法です。デフォルトでは emerge --search は与えた検索キーワードをタイトル (の一部または全体) に含むパッケージの名前を出力します。
例えば、名前に "pdf" を含むパッケージを探してみましょう:
user $emerge --search pdfパッケージの説明文も検索対象にするには、--searchdest (か -S) オプションを使います:
user $emerge --searchdesc pdfこの出力には様々な情報が含まれています。各項目にはわかりやすいラベルがついているので、ここでその意味を説明する必要はないですね:
* net-print/cups-pdf
Latest version available: 1.5.2
Latest version installed: [ Not Installed ]
Size of downloaded files: 15 kB
Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
Description: Provides a virtual printer for CUPS to produce PDF files.
License: GPL-2
ソフトウェアのインストール
ソフトウェアの名前がわかったら、インストールは emerge コマンドを実行するだけです。例えば gnumeric をインストールするにはこうします:
root #emerge --ask app-office/gnumeric多くのアプリケーションは互いに依存しあっているので、あるソフトウェアパッケージのインストールにはいくつかの依存パッケージのインストールを伴う場合があります。でも大丈夫、Portageがちゃんと依存関係を見ています。Portageがインストールしようとしているものを確認するには、--pretendオプションを付けます。例えば:
root #emerge --pretend gnumeric上と同じことをしつつ、インストールを続行するかどうか対話的に選択するには、--ask フラグを追加してください:
root #emerge --ask gnumericパッケージのインストールの過程で、Portageは(必要なら)ソースコードをインターネット上からダウンロードし、デフォルトでは /var/cache/distfiles/ に保存します。インストールせずにダウンロードだけさせたい時は、--fetchonly オプションを emerge コマンドにつけます。
root #emerge --fetchonly gnumericインストールしたパッケージのドキュメントを探す
多くのパッケージにはドキュメントが付属しています。そしてドキュメントをインストールするかどうかを選択する doc USEフラグが用意されていることがあります。パッケージで doc USEフラグが使われるかどうかは、emerge -vp category/package で調べることができます:
root #emerge -vp media-libs/alsa-libThese are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] media-libs/alsa-lib-1.1.3::gentoo USE="python -alisp -debug -doc" ABI_X86="(64) -32 (-x32)" PYTHON_TARGETS="python2_7" 0 KiB
ドキュメントはそれをインストールしたいパッケージにのみインストールしたいでしょうから、doc USEフラグは /etc/portage/package.use でパッケージごとに指定することをお勧めします。詳しくは USE フラグの節 をご覧ください。
パッケージをインストールすると、ドキュメントはたいてい /usr/share/doc/ 内のパッケージ名のディレクトリで見つけることができます:
user $ls -l /usr/share/doc/alsa-lib-1.1.3total 16 -rw-r--r-- 1 root root 3098 Mar 9 15:36 asoundrc.txt.bz2 -rw-r--r-- 1 root root 672 Mar 9 15:36 ChangeLog.bz2 -rw-r--r-- 1 root root 1083 Mar 9 15:36 NOTES.bz2 -rw-r--r-- 1 root root 220 Mar 9 15:36 TODO.bz2
ドキュメントファイルを一覧表示するもっと確実な方法は、equery の --filter オプションを使うことです。equery は Portage のデータベースを検索するために使われるもので、app-portage/gentoolkit パッケージの一部としてインストールされます:
user $equery files --filter=doc alsa-lib* Searching for alsa-lib in media-libs ... * Contents of media-libs/alsa-lib-1.1.3: /usr/share/doc/alsa-lib-1.1.3/ChangeLog.bz2 /usr/share/doc/alsa-lib-1.1.3/NOTES.bz2 /usr/share/doc/alsa-lib-1.1.3/TODO.bz2 /usr/share/doc/alsa-lib-1.1.3/asoundrc.txt.bz2
--filter オプションを他のルールとともに使えば、他の種類のファイルのインストール場所を見るためにも使えます。他の機能については equery の man ページで確認できます: man 1 equery。
ソフトウェアの削除
ソフトウェアをシステムから安全に削除するには、emerge --deselect を使います。これは Portage に、パッケージがもう必要でないので、--depclean によるクリーンアップの対象であることを伝えます。
root #emerge --deselect gnumericパッケージが選択されなくなっても、そのパッケージと、そのパッケージが必要としたために自動的にインストールした依存パッケージはまだ残っています。このような削除可能なパッケージを洗い出すには、emergeの --depclean 機能を使いますが、これは後ほど説明します。
システムの更新
システムをきれいに保つため (そしてもちろん最新のセキュリティアップデートを適用するため) には、日常的にシステムを更新する必要があります。Portage は Gentoo リポジトリに入っている ebuild しか確認しませんから、最初にすることは emerge --sync を使用してリポジトリを更新することです。そして、emerge --deep --update @world でシステムを更新することができます。
--deep を使用することで、Portage はインストール済みのアプリケーションに新しいバージョンがあるかどうかを調べます。--deep を使用しない場合、明示的にインストールされたアプリケーション (/var/lib/portage/world に記載されているもの) のみが対象で、それらの依存パッケージはチェックされません。そのため、ほとんど常にこのオプションを使用するべきです:
root #emerge --update --deep @world標準的なアップグレードコマンドは、リポジトリのプロファイル内に変更がある可能性から、またはシステム USE 設定が変更されている場合のために、--changed-use または --newuse を含むべきです。これにより、その変更に新しいパッケージのインストールや既存パッケージの再コンパイルが必要でないかどうか、Portage が調べてくれます。
root #emerge --update --deep --newuse @worldメタパッケージ
Gentooリポジトリの中には、それ自体は中身を持たず、パッケージの集合をインストールするためだけに用意されたパッケージが存在します。例えば kde-plasma/plasma-meta パッケージは、Plasma関連の様々なパッケージを依存に持つことで、KDE Plasmaデスクトップをインストールします。
このようなパッケージをシステムから削除しようと emerge --deselect を実行しても、そのパッケージの依存パッケージはシステムに残るため、あまり効果がありません。
Portageは、孤独な依存関係を削除する機能も備えています。しかし、ソフトウェアの可用性は動的依存のため、まずシステム全体を完全にアップデートすることが重要です。これにはUSEフラグの変更が適用された新しい変更も含みます。これの後、emerge --depcleanを実行し、孤独な依存関係を削除することが出来ます。これが完了したら、今削除されたソフトウェアと動的にリンクしていたが、もはやそのソフトウェアを必要としないアプリケーションの再ビルドが必要かもしれません。尤も、最近このサポートはPortageに追加されましたが。
以上のことのすべては次の 2 コマンドで行われます:
root #emerge --update --deep --newuse @world
root #emerge --ask --depclean
ライセンス
Portage バージョン 2.1.7 以降、ライセンスを基準にソフトウェアのインストールを許可または拒否することができます。ツリー内のすべてのパッケージは LICENSE エントリを含みます。emerge --search category/package を実行するとパッケージのライセンスが表示されます。
免責事項および法的な責任の境界として、ebuild の LICENSE 変数は Gentoo の開発者やユーザにとっての単なるガイドラインです。これは法的な声明でも、ebuild によってインストールされるすべてのファイルのライセンスを反映していることの保証でもありません。パッケージによって提供されるすべてのファイルの完全に正確な法的表現として信頼するべきではありません。確証を得るためには、システム管理者はパッケージによってインストールされるすべてのファイルについて、適切なライセンスの連携と準拠がされているか、掘り下げてチェックするべきです。 もし ebuild に食い違いを見つけた場合は、その ebuild の LICENSE 変数に割り当てられた値の変更を提案するために、バグを提出してください。
Portage はデフォルトでは、フリーソフトウェア財団、Open Source Initiativeによって明示的に承認されたライセンス、あるいは自由ソフトウェアの定義に従っているライセンスを許可します。
許可するライセンスを制限する変数は ACCEPT_LICENSE と呼ばれ、/etc/portage/make.conf ファイル内で設定できます。次の例はデフォルト値を示しています:
/etc/portage/make.confデフォルトのACCEPT_LICENSE設定ACCEPT_LICENSE="-* @FREE"
この設定の下では、自由ソフトウェアライセンスあるいは自由な文書ライセンスが設定されているパッケージがインストール可能となります。フリーではないソフトウェアはインストールできなくなります。
ACCEPT_LICENSE は /etc/portage/make.conf 内でグローバルに設定することもできますし、/etc/portage/package.license ファイル内でパッケージ毎に定義することもできます。
たとえば、google-chrome ライセンスを www-client/google-chrome パッケージのために許可するには、/etc/portage/package.license に次の内容を追加してください:
/etc/portage/package.licensegoogle-chromeライセンスをgoogle-chromeパッケージのみについて受諾するwww-client/google-chrome google-chrome
これにより www-client/google-chrome パッケージのインストールは許可しますが、同じライセンスを持っていたとしても www-plugins/chrome-binary-plugins パッケージのインストールは禁止されます。
または、よく必要になる sys-kernel/linux-firmware を許可するには:
/etc/portage/package.licenselinux-firmware パッケージに関してライセンスを受諾する# linux-firmware に関してライセンスを受諾する
sys-kernel/linux-firmware linux-fw-redistributable
# 再配布を許可するすべてのライセンスを受諾する
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
ライセンスは /var/db/repos/gentoo/licenses/ ディレクトリに保管され、ライセンスグループは /var/db/repos/gentoo/profiles/license_groups ファイルに記録されます。各行の大文字で書かれた最初のエントリはライセンスグループの名前で、それに続くすべてのエントリは個々のライセンスです。
ACCEPT_LICENSE 変数内で定義されるライセンスグループは @ 記号で始まります。ありうる（かつてPortageのデフォルトだった）設定は、使用許諾契約書を読み同意する必要があるEnd User License Agreements（使用許諾契約、EULA）を除いてすべてのライセンスを受諾する設定です。これを実現するには、次のように、現在許可されているすべてのライセンスを受諾し（*を使います）、その後 EULA グループ内のライセンスのみを受諾取り消ししてください:
/etc/portage/make.confEULAを除くすべてのライセンスを受諾するACCEPT_LICENSE="* -@EULA"
この設定は、フリーではないソフトウェアや文書も受諾する事に注意してください。
Portage が文句を言ってきたときは
用語について
前述の通り、Portage は非常に強力で、他のソフトウェア管理ツールにはない多くの機能をサポートしています。これを理解するために、Portage のいくつかの観点について、深追いしすぎない程度に説明していきます。
Portage を使うと、ひとつのパッケージの異なる複数のバージョンをシステム上に共存させることができます。他のディストリビューションはパッケージ名をバージョンにちなんで命名する（例えば gtk+2 と gtk+3 のように）ことが多いですが、Portage はスロット（SLOT）という技術を使用します。各 ebuild はそのバージョンに応じてひとつのスロットを宣言します。異なるスロットを持つ ebuild は同一システム上に共存できます。例えば、gtk+ パッケージの ebuild には SLOT="2" のものと SLOT="3" のものが存在します。
同じ機能を提供するものの、実装の異なる複数のパッケージというものもあります。例えば、metalogd、sysklogd、syslog-ng はすべてシステムロガーです。"システムロガー"の利用を前提とするアプリケーションは、例えば、metalogd に依存するわけにはいきません。他のシステムロガーも同じくらい良い選択肢でありうるからです。そこで Portage は仮想（virtual）パッケージというものを許容しています。各システムロガーは、virtual カテゴリの logger 仮想パッケージの"排他的な"依存パッケージとしてリストされていて、アプリケーションはvirtual/logger パッケージに依存すればいいようになっています。このパッケージをインストールすると、すでにロギングパッケージがインストールされていない限り（この場合は仮想パッケージの依存が解決していることになります）、言及されている最初のロギングパッケージがインストールされます。
Gentoo リポジトリのソフトウェアは異なるブランチに所属できます。デフォルトでは、システムは Gentoo が安定している（stable）と考えるパッケージだけが許容されます。ほとんどの新しいソフトウェアタイトルは、コミットされた時点ではテスト中（testing）ブランチに追加されます。stable としてマークする前にまだテストが必要だということです。こうしたソフトウェアの ebuild は Gentoo リポジトリ内に存在していますが、stable ブランチに置かれるまで Portage はこれらをアップデートしません。
一部のアーキテクチャでのみ利用可能なソフトウェアもあります。他のアーキテクチャでは動作しない、テストが不十分、そのソフトウェアを Gentoo リポジトリにコミットした開発者が異なるアーキテクチャ上で動作するか確認できない、などの理由がありえます。
それぞれのGentooインストールは、システムが通常通り機能するために必要な、パッケージのリストを含む情報を格納している特定のプロファイルに従っています。
ブロックされたパッケージ
[ebuild N ] x11-wm/i3-4.20.1 USE="-doc -test"
[blocks B ] x11-wm/i3 ("x11-wm/i3" is soft blocking x11-wm/i3-gaps-4.20.1)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(x11-wm/i3-4.20.1:0/0::gentoo, ebuild scheduled for merge) pulled in by
x11-wm/i3
(x11-wm/i3-gaps-4.20.1-1:0/0::gentoo, installed) pulled in by
x11-wm/i3-gaps required by @selected
ebuild には、それが依存するパッケージについて Portage に伝えるためのフィールドが含まれています。DEPEND 変数で宣言されるビルド時依存と、RDEPEND 変数で宣言される実行時依存です。これらの依存パッケージのうち一つが明示的にパッケージや virtual を共存できないとマークしているとき、ブロックが発生します。
最近のバージョンの Portage はささいなブロックであればユーザの手助けなしで対処できますが、ブロックを手動で解決することが必要になる場合もあります。
ユーザはブロックを解決するために、そのパッケージをインストールしないか、コンフリクトしているパッケージを先に unmerge するかを選ぶことができます。上の例でいえば、x11-wm/i3 のインストールをやめるか、先に x11-wm/i3-gaps を取り除くか選べます。通常は、例えば emerge --deselect x11-wm/i3-gaps のようにして単に Portage にそのパッケージはもう希望しないと伝え、パッケージ自体を強制的に除去するのではなく world ファイルから削除するのがベストです。
特定のアトムを対象にしたブロックもあります。例えば <media-video/mplayer-1.0_rc1-r1 のようなものです。この場合は、ブロックしているパッケージをより新しいバージョンにアップデートすることで、ブロックを取り除くことができるかもしれません。
まだインストールされておらず、今からインストールしようとしている 2 つのパッケージがお互いにブロックしあっている、ということもありえます。このレアケースでは、なぜその両方をインストールする必要があるのか調査してください。ほとんどの場合は片方だけで十分です。もしそうでなければ、Gentoo のバグトラッキングシステムにバグを報告してください。
マスクされたパッケージ
!!! all ebuilds that could satisfy "bootsplash" have been masked.
!!! possible candidates are:
- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))
現在のシステムで利用可能でないパッケージをインストールしようとしたときに、このマスキングエラーが発生します。ユーザはシステムで利用可能な別のアプリケーションのインストールを試みるか、パッケージが利用可能としてマークされるまで待つべきです。パッケージがマスクされているのには必ず理由が存在します:
| マスク理由 | 説明 |
|---|---|
| ~arch keyword | アプリケーションは stable ブランチに入れるために十分なテストがなされていません。数日から数週間待ってからもう一度試してください。 |
| -arch keyword or -* keyword | アプリケーションはターゲットアーキテクチャ上で動作しません。これが正しくなければ、バグを提出してください。 |
| missing keyword | アプリケーションはまだターゲットアーキテクチャ上でテストされていません。アーキテクチャ移植チームにパッケージのテストを依頼するか、彼らのためにテストして Gentoo の Bugzilla のウェブサイトで知見を報告してください。/etc/portage/package.accept_keywords および特定のパッケージに対してキーワードを許可するも参照してください。 |
| package.mask | パッケージが破損している、不安定、あるいはもっと悪い状態であると判明したため、意図的に「使用禁止」としてマークされています。 |
| profile | パッケージは現在のプロファイルに適していないことが判明しています。アプリケーションをインストールするとシステムが壊れるか、単に現在使用中のプロファイルと互換性がありません。 |
| license | パッケージのライセンスが ACCEPT_LICENSE の値に適合していません。/etc/portage/make.conf または /etc/portage/package.license で設定して、ライセンスまたは正しいライセンスグループを許可してください。 |
USE フラグの変更が必要
The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test
--autounmask がセットされていないと、次のようなエラーメッセージも表示されるかもしれません:
emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]".
!!! One of the following packages is required to complete your request:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])
このような警告やエラーは、インストールしようとしているパッケージが他のパッケージに単に依存しているだけでなく、そのパッケージが特定の USE フラグ（またはその集合）とともにビルドされていることも要求するときに発生します。上の例では、パッケージ app-text/feelings が USE="test" とともにビルドされていることを要求していますが、この USE フラグがシステム上でセットされていない状態です。
これを解決するには、要求された USE フラグを /etc/portage/make.conf 内でグローバル USE フラグに追加するか、/etc/portage/package.use 内で特定のパッケージに対してセットしてください。
依存パッケージが見つからない
emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem.
インストールしようとしているアプリケーションは、システムで利用可能でない他のパッケージに依存しています。この問題が既知のものかどうか Bugzilla を確認し、もしそうでなければ報告してくれると助かります。システムが複数のブランチを混ぜる設定になっていなければ、この事態は発生すべきではなく、バグです。
あいまいな ebuild 名
[ Results for search key : listen ]
[ Applications found : 2 ]
* dev-tinyos/listen [ Masked ]
Latest version available: 1.1.15
Latest version installed: [ Not Installed ]
Size of files: 10,032 kB
Homepage: http://www.tinyos.net/
Description: Raw listen for TinyOS
License: BSD
* media-sound/listen [ Masked ]
Latest version available: 0.6.3
Latest version installed: [ Not Installed ]
Size of files: 859 kB
Homepage: http://www.listen-project.org
Description: A Music player and management for GNOME
License: GPL-2
!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.
インストールすることが選択されたアプリケーションの名前が複数のパッケージに対応しています。これを解決するには、カテゴリ名も付け加えてください。Portage は何から選べばいいか、マッチしたものを教えてくれるでしょう。
循環依存
!!! Error: circular dependencies:
ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2
インストールする 2 個（またはそれ以上）のパッケージがお互いに依存しているため、インストールできません。これはほとんどの場合 Gentoo リポジトリ内のパッケージのどれかにバグがある状態です。時間をおいて再 sync してからもう一度試してください。Bugzilla をチェックしてこの問題が既知のものであるか確認し、そうでなければ報告することも有益でしょう。
フェッチ失敗
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered. Please see above for details.
Portage が与えられたアプリケーションのソースをダウンロードできなかったため、他のアプリケーションのインストール（するものがあれば）を続行しようとしています。この失敗は、正しく同期されていないミラーのために、あるいは ebuild が正しくないダウンロード先を指しているために起こることがあります。ソースを置いているサーバが何らかの理由でダウンしていることも考えられます。
1 時間ほど時間をおいて再試行し、問題が継続しているか確認してください。
システムプロファイルによる保護
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.
ユーザがシステムのコアパッケージの一部をなすパッケージを削除しようとしました。パッケージはプロファイルによって必須として記載されているため、システムから削除するべきではありません。
ダイジェスト検証失敗
>>> checking ebuild checksums
!!! Digest verification failed:
これは Gentoo リポジトリに何かおかしなことが起きていることを示しています - 多くの場合は Gentoo ebuild リポジトリに ebuild をコミットするときのミスによるものです。
ダイジェスト検証に失敗しても、自分でパッケージのダイジェストを再計算しようとしないでください。ebuild foo manifest を実行しても問題の解決にはならないどころか、より状況を悪化させるでしょう。
かわりに、リポジトリが大人しくなるまで 1、2 時間ほど待ってください。このエラーはすぐに気づかれるでしょうが、修正が rsync ミラーたちに浸透していくには少々時間がかかることがあります。Bugzilla をチェックしてすでに誰かが問題を報告しているか確認するか、#gentoo (webchat) (IRC) で聞いてください。まだであれば、遠慮なく壊れた ebuild のためにバグを提出してください。
バグが修正されたら、Gentoo ebuild リポジトリを再同期して修正されたダイジェストを引っ張ってきてください。
Gentoo ebuild リポジトリを一日一回以上同期しないように気をつけてください。公式の Gentoo ネチケットポリシーに書かれている通り（また emerge --sync を実行したときにも表示される通り）、あまりにも頻繁に同期するユーザは当面の間、それ以上の同期を禁止されます。このポリシーにも繰り返し違反する悪用者は完全にアクセスを禁止されることがあります。再同期が Gentoo の rsync ミラーに過剰な負荷を与えないようにするために、どうしても必要な場合を除いて 24 時間周期で同期されるのを待つのが最善です。