Portageマニュアル
1.
Portageの概要
概要
Portageは非常に強力で先進的なパッケージ管理システムです。Portageは柔軟性に優れており、また、比較的シンプルな構築環境の提供が可能で、最先端のLinuxディストリビューションの心臓部を形成できるため、メタディストリビューションエンジンとも呼ばれます。
Gentoo LinuxディストリビューションはPortageによって構築されています。
Gentoo Linuxは、Portageと、4000を超えるパッケージ構築レシピ(ebuildと呼ばれます)から構築されており、メタディストリビューションと呼ばれることがよくあります。
これらのebuildはPortageエンジンに対し、ソフトウェアパッケージをどのようにコンパイルしてインストールするか指示します。
各profileの利用や、emergeと呼ばれるコマンドラインユーティリティの使用を通して、ユーザと開発者は、オペレーティング・システム自体やそのシステムの上で動作するアプリケーションのインストールや管理のために、Portageを使うことができます。
Gentoo Linuxは「必要に応じてその場でコンパイル(compiled on the fly)」されるシステムです。Gentoo Linuxをインストールするということは、まずは必要十分なコンパイラとビルド環境を構築することを意味します。そしてこのコンパイラとビルド環境を使って、Portageはインターネットからソースコードをダウンロードし、残りのシステムの「核」の部分やその他必要な全アプリケーションをビルドするわけです。Portageでは、あらかじめ作成されたバイナリパッケージを使用することも可能ですが、これはある意味妥協であり、なるべくなら性能の低いコンピュータでインストールする時などに留めてください。たとえば、できるだけ早急に特定のパッケージを復旧しなくてはいけない開発者だとか、大変性能の低いコンピュータで使用するために、そのマシンより速いコンピュータでパッケージを
コンパイルするユーザなどが、これにあたるでしょう。
以上の事柄と、以下の事実 - Gentoo Linuxのインストールにおいて、パッケージのコンパイル、インストールの際に、ほんの少し手を加えるだけで柔軟に設定の変更が可能であること - は同じ意味を表しています。
つまりユーザがGentoo Linuxをインストールするという事は、Portageの設定やebuild自体に明示的にオプションを指定しながら、「Portageシステムを利用して1つのカスタマイズされたLinuxディストリビューションをコンパイルする」と言うことなのです。
一見、Portageのアイディアは伝統的なBSDのportsシステムに似ているように見えます。両方ともソースからパッケージをコンパイルして、自動的に依存性を解決するシステムであり、ユーザは安全にソフトウェアのインストールとアンインストールが可能です。多くのPortageのアイディアはBSDのportsシステムから継承したものですが、Portageは単なる"portsの二番煎じ"ではありません。
Portageシステムは、Pythonのコアの部分と、BASHスクリプトベースのebuildとの融合物であるといえます。Makefileやmakeコマンドで処理する代わりに、Pythonのパワーと、オブジェクト指向の特徴の一部を利用したシェルスクリプティングの使いやすさを活かし、Portageはユニークでパワフルなシステムを作り上げています。だから敢えて言いましょう。Portageは現在存在する他のすべてのportsシステムを超越しています。
Portageが提供する先進的な機能のうち、いくつかを紹介しましょう。Portage ツリーに存在する同じパッケージの複数のバージョンやリビジョンを共存できること。条件付きの依存関係チェックや付加機能の選択機能。きめ細かいパッケージ管理や「サンドボックス」化された安全なインストール。設定ファイルの保護機能や、profile機能、など、など、など。これらの特徴の多くは、このマニュアルの後編で詳細に説明していきます。
条件付きの依存性解決およびその支援の特徴
Portageシステムは、それがユーザに提供する柔軟性の量においてほかに例がありません。伝統的なBSD portsシステムは、portsツリー内で1つのパッケージに対して1つのリビジョンしかサポートできません。Portageには、そのような制限がありません。同じパッケージの複数のバージョンをインストールして同時に利用可能です。パッケージ依存(コンパイル時に必要なものや、他のパッケージを利用している場合)は、そのパッケージ名もしくはバージョンを付加した名称で特定することができます。これにより、複数のバージョンをツリーで安全に利用できるようにしています
依存性システムはまた、条件つきの依存をもサポートします。 Portageは、USEフラグシステムと呼ばれている強力な機能を持ちます。Portage構成ファイルにおいて1つの構成変数を変えることによって、ユーザはコンパイル時に全てのパッケージに対して特定の機能またはライブラリに対するオプションのサポート(そして、そのパッケージに依存する必要性)を無効にすることが可能です。これは、次の章においてより詳しく説明される非常に柔軟で強力なシステムです。
さらに、PortageはSLOTの機能を持ちます。 Gentoo Linuxの開発の中で、我々は以下のことに気がつきました - ある特定のパッケージ(たとえばライブラリ)に関しては、その他のさまざまなパッケージによる要求を満たすために、複数のバージョンを同時にインストールしておく必要があるのです。この問題の従来の解決方法は、同じパッケージの異なるバージョンに対して、わずかに異なる名称をつけておくことでした。
特定のバージョンを別々のパッケージとみなす事を研究しているデベロッパー達に代わって、我々はPortageに対し、SLOTの機能を用いつつ、いかに複数のバージョンを同じパッケージであると扱わせ、維持させるかを教えたのです。この例として、freetypeとして知られている一般的なライブラリについて考えて見ましょう。freetypeの1.xは2.xと共存しません。しかし、両方のバージョンはいろいろなパッケージの依存を満たすために必要です。ほとんどのディストリビューションと ports は freetype 1.x には"freetype" を 2.x には "freetype2" とすることが多いです。こういう解決方法はそのパッケージ管理システムに根本的な不備があることを端的に表していると我々は考えます。
我々は単純に前者(freetype1)に SLOT ナンバー1を、後者(freetype2)にSLOTナンバー2を割り当てました。この情報により、オリジナルのブランチに対して個別に更新が行われたとしても、Portageは両方のバージョンを追跡して、アップグレードを行うことが可能なのです。
profile
Portageは、profileの機能をサポートしています。 profileは、指示子(directive)を付与されたパッケージの名称とバージョンのリスト、そしてPortageによってデフォルトとして使用されるコンフィギュレーションオプションを保持しています。profileはPortageに対して、パッケージ(もしくはそのパッケージの特定のバージョン)が無効であるか、有効であるか、もしくは必須として扱われるべきかをPortageに指示します。また、ユーザは、1つのシンボリックリンクを変更するだけでprofileを切り替えることができます(/etc/make.profile)。これは単純なことのようですが、このことがPortageをディストリビューションの核、また「プロフェッショナル」級のビルドシステムにしているのです。
Gentoo Linuxの運用においては、Portageによって使用される複数のebuild、そして1つのprofileの管理について、ほとんどの労力をつぎ込むことになります。このprofileは、どのパッケージがシステムのオペレーションに不可欠な「中心的な」パッケージと考えられるかについて定義しています。profileは、開発者達が一時的に不良なパッケージ等をブロックしたり、ブロックを解除させたりすることができるようになっています。Portageは、実際にどのようにパッケージをビルド、インストールするかを、profileによる有効、無効の情報と、ebuildファイルにより解釈します。
2.
Portageの設定
概要
この章ではさまざまな局面におけるPortageの設定を網羅します。ユーザと開発者のどちらにとっても重要となるでしょう。Portageは大変柔軟なシステムであり、ユーザは必要に応じて自分のシステムをチャージ及び、最適化するために、Portageを設定する方法を理解する必要があります。
このドキュメントで"ユーザ"とあるのはPortageとシステム設定を変更する管理者権限を持った人を意味しているということに注意してください。ユーザはPortageの設定変更とパッケージの追加と削除をするためにrootにならなければなりません。
Portage設定ファイル
下で説明される構成オプションのほぼ全ては、/etc/make.conf、/etc/make.profile/make.defaultsと/etc/make.globalsにあります。"Portageに使用される多数の変数は/etc/make.confにあります。Portageはどんな設定よりもまず最初に現在の環境変数をチェックします。環境変数が見つからない場合、Portageは次に/etc/make.confをチェックします。/etc/make.confでも設定が見つからない場合、Portageは/etc/make.profile/make.defaultsをチェックします。そこでも設定が見つからない場合、デフォルトの設定は/etc/make.globalsを使うことになります。すべてのユーザの設定の中で環境変数、または/etc/make.confはユーザにより変更されやすいということに注意してください。"重要なことですが、/etc/make.confで定義される設定が/etc/make.globalsのどんな設定をも、ほぼ常に上書きしてしまうということに注意してください。Portageに関する限り、/etc/make.conf
と/etc/make.globalsはシステム全体に渡るグローバルな設定と考えることができます。
既に定義されたオプションがどこにあるか確認したい場合は、まず/etc/make.confを確認し、次に/etc/make.globalsを確認することをお勧めします。特に指定しない限り、/etc/make.confで設定されているオプションが/etc/make.globalsのオプションを上書きします。
USEフラグ
USEフラグシステムはパッケージ構築時において、さまざまな特性を個々のパッケージに対して、もしくはグローバルなレベルで、有効か無効にする柔軟な方法です。これにより管理者は、それらのパッケージのコンパイル時に指定できるオプショナルな機能をコントロールできるようになります。たとえば、GNOMEのサポートをオプションで備えているようなパッケージは、USEフラグ「gnome」を無効にすることにより、コンパイル時にそのサポートを無効にすることができます。そのパッケージでGNOMEサポートを有効にしたい場合には、USEフラグgnomeをオンにするだけです。
パッケージにおけるUSEフラグの効果は、ソフトウェア自身と、USEフラグをオプション機能としてサポートしているebuildの両方に依存しています。ソフトウェアがサポートしていないオプションについては、それに対するUSEフラグは(当然ながら)全く効果はありません。
また、パッケージ依存関係の多くはソフトウェアにとっては「オプション」であるとは言えません。そのため、依存関係のうち必須のものに関しては、USEフラグは全く効力を発揮しません。
特定のパッケージで使用されるUSEフラグのリストは、どんなebuildファイルにでもおいてDEPENDとRDEPENDの行をチェックすることによって見つかります。
Gentoo Linuxによって使用されるUSEフラグのリストは/usr/portage/profile/use.descにあります。
個々のUSEフラグについては、そのUSEフラグでできることに対しての簡単な要約とともに、1行に1つの形式でリストアップされています。
Portageは、USEフラグが有効か無効かを、最高4箇所をチェックすることによって判断します。それらは「スタックに積むような」感じでUSEフラグを変化させます。Portageは、それらの設定箇所を順に見ていく間、前の設定箇所で設定が無効であったか有効であったかを記憶しておきます。USEフラグは、Portageによる各設定箇所の巡回の間、「蓄積されるような形で」変化していきます。
USEフラグの設定箇所と、Portageがそれらをチェックする順序に関しては、/etc/make.globals内のUSE_ORDERによって設定されます。設定箇所を無効にする場合は、ユーザは単にUSE_ORDERからそれを取り除くだけです。
以下では、Portageのデフォルトの設定においてUSE_ORDERに定義されている順番に、各設定箇所に関する説明を行います。
defaults
Portage profileは、デフォルトのUSEフラグを定義することができます。これはいかなるPortage profileにおいても、make.defaultsファイルにおいて設定されます。
/etc/make.profileをPortage profileに対するシンボリックリンクに用いている場合には、デフォルトの設定では/etc/make.profile/make.defaultsとなります。将来のprofileに対する変更により、あなたが行った変更内容が上書きされて失われてしまう可能性があるので、このファイルは編集しないことをおすすめします。
auto
Portage profile内において、use.defaultsファイルにより定義されます(/etc/make.profile/use.defaults)。
それぞれのエントリは、USEフラグと対応するパッケージから成ります。
もしUSEフラグに対応するパッケージがインストール済みであれば、そのパッケージに関するUSEフラグは有効であると判断されます。
たとえば、x11-base/xfreeをインストール済みで、かつ以降の設定箇所ではっきりとXのUSEフラグを無効にしなかったとしましょう。
すると、USEフラグ「X」は、xfreeがインストールされている間はグローバルに有効となります。将来のprofileに対する変更により、あなたが行った変更内容が上書きされて失われてしまう可能性があるので、このファイルは編集しないことをおすすめします。
conf
もし、USEフラグが/etc/make.conf内で定義されていたならば、そのフラグは評価対象となります。make.confで定義されなかったUSEフラグに関しては、/etc/make.globalsがチェックされます。
この項目(USEフラグの設定)は、以下のようになります:
コード表示 2.1 |
USE="slang readline gpm berkdb gdbm tcpd pam libwww ssl gb tk
lm_sensors lvm ldap tex bonobo sdl gtk xfs evo pda ldap
mmx mitshm perl python guile ruby postgres dvd 3dnow tcl
lcms gif sdl vorbis ogg oss libg++ directfb decss snmp
gnome X opengl mozilla pdflib gpg -nls gd xface jpilot
-kde -qt -esd -motif -alsa oggvorbis"
|
USEフラグは、設定名をリストするだけで有効にできます。USEフラグは、設定名の前に-(マイナス記号)を置くことで無効にできます。たとえば、gnomeはGNOMEを有効に、-motifはmotifを無効にします。
パッケージの有効、無効を明示的に指定するキーワードは、/etc/make.confのUSEフラグに書くすることが推奨されています。Portageはこのファイルを自動的に上書きしません。
もしあなたが、USEフラグの中で有効、もしくは無効にしたいものがあるけれども前述の2つの設定箇所でその設定をしたくない場合、このファイルで行うことが推奨されます。
env
USEフラグ設定は、シェルの環境変数により手動で上書きできます。
コード表示 2.2 |
export USE="-gnome"
emerge net-im/gaim
|
このことにより、ある特定のパッケージを取り込む際、いくつかのUSEフラグを行うことが可能になっています。
シェル環境でのUSEフラグの設定は、USE環境変数が有効である限り、今後そのシェル内で呼び出されるあらゆるemergeに影響を与えます。
注意:
Portageが現在記憶しているUSEフラグ(パッケージを取り込む際に設定したUSEなど)は、恒常的なものではありません。
パッケージが将来再度取り込まれたり、アップグレードされたりする際には、その時点で有効なUSEフラグが使用されます。
パッケージの最初のマージの際に使用されたUSEフラグは、もはや有効ではありません。
|
コンパイラオプション
パッケージをコンパイルするためにPortageによって使用されるコンパイラ・オプションは、CHOST、CFLAGSとCXXFLAGSの各行を編集することにより/etc/make.confで設定できます。CHOST設定はユーザがどのプラットホームを編集しているかについて指定します。CFLAGSとCXXFLAGS設定は、それぞれCとC++のコンパイル時に使われるコンパイラフラグを指定します。
デフォルト設定のうち、安定し、テスト済みであるプラットフォームに関しては、コメントの中に記述されています。
テスト済みのデフォルト設定を変更すると、コンパイラ、またはコンパイルされるソフトフェアの両方で、コンパイルエラーやバグに遭遇することになるかもしれません。
最終的に動かないシステムで終わらないように、デフォルト設定の修正を行うのは慎重に行ってください。
マルチプロセッサ・システムをもつユーザは、/etc/make.globals内のMAKEOPTSオプションを修正することでなんらかの利益を得られる可能性があります。このオプションは、パッケージコンパイルの際に複数のgccを並列実行させることができるようmakeコマンドに渡されることになります。
ディレクトリパス
あなたは、Portageがパッケージの構築に使用したり、さまざまなファイルを保存しておくために使用するディレクトリを変更することが可能です。
多くのユーザはこれらの位置を変更する必要はありません。
オプションは以下のようにセットできます:
-
PORTDIR - Portageツリーのディレクトリ
-
DISTDIR - ダウンロードしたアーカイブのローカルキャッシュ
-
PKGDIR - ローカルで生成したtbz2パッケージのディレクトリ
-
RPMDIR - ローカルで生成したrpmパッケージのディレクトリ
-
CURRENTFILE - ???(訳注:原文通りです)
-
PORTAGE_TMPDIR - パッケージのコンパイルのために使用する
一時ディレクトリ
-
BUILD_PREFIX - PORTAGE_TMPDIRに関連
-
PKG_TMPDIR - PKGDIRに関連
設定ファイルの保護
Portageは特定のディレクトリにおけるあらゆる設定ファイルの保護が可能です。
Portageは保護されたディレクトリ内ではファイルの上書きを行いません。
もしも既にインストールされているパッケージのインストールをしようとするならば、設定ファイルは._cfg0000_nameというようなファイル名にリネームされます。
この動作は、ユーザが後から新しいファイルを探すことと、手動で2つのファイルの違いをマージすることを可能にします。
保護されたディレクトリは/etc/make.confもしくは/etc/make.globalsの中にCONFIG_PROTECTとして設定できます。保護されたディレクトリ中の特定のファイルや、サブディレクトリはCONFIG_PROTECT_MASKで設定することにより保護を無効にすることもできます。
以下はそのサンプルです、そのままコピーして使用しないでください:
コード表示 2.3 |
CONFIG_PROTECT="/etc /usr/share/config /usr/kde/2/share/config"
CONFIG_PROTECT_MASK="/etc/gconf /etc/init.d /etc/pam.d"
|
ユーザは、どのようにファイル保護設定が機能するか、次のようにタイプしてその情報を表示することができます:
コード表示 2.4 |
emerge --help config
|
機能
Portageは開発者向けのオプションをいくつか提供しています。それらのオプションを利用することにより、パッケージのマージで生じるいくつもの段階において、Portageの動作やPortage後のクリーンアップの挙動を制御できるようになります。
これらのオプションは、開発者向けのものですので、ユーザが使用した場合問題を引き起こすかもしれません。
有効にする機能のリストは、/etc/make.confか/etc/make.globalsで
FEATURESによって設定できます。
以下は、利用できるオプションのリストです:
-
digest : 自動的に新しいebuildのダイジェストを作成する。
-
cvs : 自動的に新しいダイジェストをcvsにコミットする。
-
sandbox : 作業ディレクトリ以外への書き込みを禁止する(sandbox)。
-
noclean : Portage動作後、決してcleanしない。
-
noauto : 自動的に先のebuildステップを実行しない。
-
distcc : distccを利用した並列コンパイルを使用する。
-
ccache : コンパイルされたオブジェクトファイルを保持しておくため、リコンパイルにかかる時間が短縮される。
-
buildpkg : emergeを行うたびに、バイナリパッケージを作成する。
-
userpriv : コンパイル時、root権限を使用しない。
-
usersandbox : userprivが有効な場合、sandboxを使用する。
-
keeptemp : マージ後、一時ファイル(${T})を消去しない。
これらの機能のうちいくつかは、以下の変数を設定することで更なる微調整が可能です :
-
CCACHE_SIZE : ccacheで利用可能なディスクスペースのサイズを指定します。デフォルト値は2GBです。
-
DISTCC_HOSTS : distccを有効にした並列コンパイルの際、並列稼動するホストを定義します。これらのホストでは、distccdデーモンが動いている必要があります。
Portage SYNC設定
Portageは、rsyncによってPortage ツリーを更新することができます。
もしあなたが、Portageツリーを別の方法で更新したいと思った場合には、/etc/make.conf内のSYNCを設定することにより、Portageがとるべき振る舞いを定義することが可能です。
RSYNC
rsyncは、Portage ツリーを更新するための最も一般的な方法です。
rsyncを使用するためには、/etc/make.confに以下のように設定します:
コード表示 2.5 |
SYNC="rsync://cvs.gentoo.org/gentoo-x86-portage"
|
注意:
rsyncは、Portage ツリーのローカルコピーに対して、(あなたの行った修正などお構いなしに)盲目的に上書きをおこなってしまいます。
もしあなたがローカルに対して行った修正を保持しておく必要がある場合には 、PORTDIR_OVERLAY="/some/dir/where/you/keep-your-tree"のように設定して、自身の行った修正を保護してください。
|
注意:
あなたの地域に近いrsyncのミラーサーバを検索するようSYNCを設定するには、/etc/make.confを見て下さい。
あなたにとって地理的に近く、転送速度がより速いであろうサーバを選択することになるでしょう。
そうすることにより、多くのサーバの負荷を分散する助けにもなるのです。
|
開発者用CVS
CVSツリーにフルアクセスできる開発者は、RSHまたはSSHを用いてアクセス可能なCVSリポジトリに対し、emerge syncによってローカルツリーを同期することが可能です。
個人のアカウントを使用しCVSツリーをチェックアウトしたら、それを/usr/portageに移動し、以下のSYNCオプションを使用します:
コード表示 2.6 |
SYNC="cvs://youraccount@cvs.gentoo.org:/home/cvsroot"
|
ミラー
Gentooプロジェクトは、Portage ツリー内のebuildに関連付けられた、全てのアーカイブファイルをローカルミラーとして保存しています。
しばしば、オリジナルのソースtarballなどは、遅く、ときどきダウンしてさえいるようなサーバに保管されていることがあります。
またオリジナルの開発者は、新しいバージョンをリリースした際にftpサイトから古いバージョンを削除してしまうこともあります。
Gentoo ディストリビューションを使用する人々の人生を楽チンなものにするため、(そしてオリジナルソースサイトの帯域幅使用率の低減のため、)
我々はこれらのファイルをミラーしています。
よって、多くのミラーサイトの中から、あなたにとって物理的に近いサイトからアーカイブのダウンロードを行うことにより、速度と信頼性をより高めることになるのです。
あなたがパッケージを取り込もうとしたとき、Portageはまず我々が用意したミラーサイトにアーカイブがあるかどうかをチェックします。もしミラーサイトに要求されたファイルがなかった場合、Portageはebuildに指定されたHTTP、もしくはFTPサーバからダウンロードしようと試みます。
Portageが使うミラーサイトは、/etc/make.confでGENTOO_MIRRORSによって指定できます。
以下は、現在のデフォルトの設定です:
コード表示 2.7 |
GENTOO_MIRRORS="http://www.ibiblio.org/gentoo"
|
さらに近くの Gentooミラーサイトを探す為には、
Gentooウェブサイトをチェックするか親しい国内のメーリングリストで聞いてみてください。
プログラムのダウンロード
Portageが保管ファイルをダウンロードするのに使用するプログラムは、
FETCHCOMMANDとRESUMECOMMAND設定をセットすることによって指定できます。いくつかの例は、/etc/make.confと/etc/make.globalsで確認できます。
Portageは多くのユーザの必要性に応えるために、デフォルト設定ではwgetを使用します。
注意: Portageは、HTTP_PROXY、FTP_PROXY環境変数を使用して、HTTPプロキシ、もしくはFTPプロキシに関する情報をダウンロードプログラムに渡します。
|
プロキシ
ファイルをダウンロードするときHTTPプロキシ、もしくはFTPプロキシを使うように、Portageに対して指定できます。プロキシは、/etc/make.confか/etc/make.globalsでHTTP_PROXYとFTP_PROXYを設定することによって指定できます。
HTTPとFTPが同じプロキシで利用できるならば、代わりにPROXYを設定することもできます。
以下はサンプルです:
コード表示 2.8 |
HTTP_PROXY="http://192.168.1.1:8080"
FTP_PROXY="http://192.168.1.1:8080"
or
PROXY="http://192.168.1.1:8080"
|
Portageは、また、RSYNCの用途に、HTTPプロキシを使うように設定できます。
RSYNCプロキシの使用は、/etc/make.confでRSYNC_PROXYオプションを設定することによって、または環境変数としてそれを設定することによって指定できます。
以下はその例です:
コード表示 2.9 |
RSYNC_PROXY="192.168.1.1:8080"
|
注意:
もしあなたがファイアウォール内部にいて、rsyncがあなたのHTTPプロキシを使用できないようであれば、あなたは「スナップショット」tarballを利用してPortage ツリーの更新を行うことも可能です。
「スナップショット」tarballはhttp://www.ibiblio.org/gentoo/snapshots/から利用できます。
|
その他諸々、オプション等
次はユーザには使われることはめったに無いオプションです:
-
NOCOLOR : ユーザはemergeツールに対し、画面への出力で色を使用しないよう設定できます。
-
CLEAN_DELAY : Portageはパッケージのアンマージを行う際、指定された秒数だけ待機してユーザにキャンセルする機会を与えます。
このオプションに数値を指定することにより、その秒数を指定することができます。「0」を指定すると、その機能自体無効にすることができます。
3.
パッケージ管理
Portageツリーの更新
/usr/portageにあるPortageツリーは、さまざまなパッケージのビルド手順(ebuildと呼ばれる)を大量に保管しています。ツリーはまた、システムを最新にしておくために不可欠であるprofileとpackage.mask情報を含んでいます。
パッケージの最新バージョンやバグフィックスを利用するためには、このツリーを常に更新し、公式のPortage ツリーと同期させておくことが重要です。
以下のようにタイプすることによってPortageツリーを更新することができます:
emergeがローカルPortageツリーを更新するために使用する方法を変更することができます。
詳細はPortage設定の章においてPortage SYNC設定を見てください。
パッケージのマージ
Portageを通してパッケージのコンパイルとインストールを行うことは
マージングと言います。Portageはパッケージをコンパイルし、一時的にそれらを"image"ディレクトリにインストールします。これらのファイルはその後、imageディレクトリから移動され、本当のファイルシステムにマージされます。
emergeコマンドはPortageシステムでフロントエンドのコマンドとして動作します。
パッケージのインストールや削除はそのいろいろなコマンド・ライン引数を用いて操作できます。
最新のマスクされてないバージョンのパッケージをインストールするためには単にパッケージの名前を指定し、次のようにタイプします:
このコマンドは、いくつかの必要な依存関係にあるパッケージ(どんなUSEフラグも考慮に入れる)をコンパイル、インストールし、それから最新のマスクされてないバージョンのgaleonをコンパイル、インストールします。Galeonはまたカテゴリーと全部の名前を使用することもできます:
net-www/galeon
このemergeコマンドはまた、ebuildファイルを直接指定することもできます。
これにより、旧バージョンのパッケージをマージしたり、
サードパーティーによるebuildベースのパッケージをマージすることができます。
以下はそのサンプルです:
コード表示 3.3 |
emerge /usr/portage/net-www/galeon/galeon-1.2.0-r3.ebuild
|
さらに、マージされるパッケージ名またはebuildファイルを指定する時、
emergeは非常に便利ないくつかのコマンドライン引数をサポートします。これらの引数の中でも --pretend はおそらくもっとも便利なものです。この引数が使用されると、実際にはインストールされません。その代わりに、Portageはコマンドを実行する間、インストール対象や更新するパッケージのリストを表示します。以下は、kdevelopパッケージの最新版のインストールの時、何のパッケージがマージされるかのリストの例です:
コード表示 3.4 |
root@kodiak blocke # emerge --pretend kdevelop
These are the packages that I would merge, in order.
Calculating dependencies ...done!
[ebuild N ] kde-base/kdelibs-2.2.2-r4 to /
[ebuild N ] dev-util/kdbg-1.2.2 to /
[ebuild U ] app-text/psutils-1.17 to /
[ebuild U ] app-text/a2ps-4.13b-r3 to /
[ebuild U ] app-text/jadetex-2.20 to /
[ebuild N ] app-text/sgmltools-lite-3.0.3-r2 to /
[ebuild N ] kde-base/kdoc-2.2.2-r1 to /
[ebuild N ] net-www/htdig-3.1.5-r2 to /
[ebuild N ] app-text/enscript-1.6.3-r1 to /
[ebuild N ] kde-base/kdebase-2.2.2-r2 to /
[ebuild N ] app-doc/qt-docs-2.3.1 to /
[ebuild N ] dev-util/kdevelop-2.0.2 to /
|
上記のリストにおいて、Nというマークがあるパッケージは、
まだインストールされていないパッケージで、今回のemergeによってインストールされます。
Uというマークがあるパッケージはパッケージの以前のバージョンがすでにインストールされたことを示し、そして、今回のemergeにより各パッケージがアップグレードされます。
その他の利用可能な引数:
--fetchonly : インストールされるパッケージと、依存性のあるパッケージをコンパイルするのに必要な、アーカイブファイルをダウンロードする(だけ)。
--emptytree : このオプションを指定すると、Portageに対して、そのパッケージの依存関係やそのパッケージが依存しているパッケージがまったくインストールされていないかのように見せかけます。--pretendオプションと共に用いると、どんな特殊なパッケージに対しても完全な依存性を表示することができ、役立ちます。
glibcを除くすべての依存性が表示されます。
--nodeps : Portageは指定のパッケージのみのマージを試み、どんな依存性をも無視します。もし先に該当する依存ファイルをインストールしてない場合、コンパイルに失敗するかもしれません。
--onlydeps : 指定されたパッケージの依存するファイルのみマージされます。
指定したパッケージはマージされません。
--noreplace : 既にインストールされている場合は指定したパッケージのマージをスキップします。
--usepkg : 指定したパッケージのコンパイルをする代わりに、Portageは指定された場所から既にコンパイルされたtbz2の形式のパッケージの使用を試みます。
コンパイル済みパッケージがある場所は、シェルの環境変数PKGDIRにより指定することができます。
--debug : ebuild環境はより話言葉に近くなるようになります。
これはBASHスクリプトベースのebuildファイルでエラーと格闘する開発者に役立ちます。
--autoclean : emergeは、パッケージのビルドを行う直前に、パッケージ固有の一時作業ディレクトリをクリーンアップします。
Portageはこの動作を初期状態で行うので、このオプションは
初期状態で無効に設定している開発者にとって役立ちます。
--verbose : emergeを冗長モードで動作させます。
現在、これはGNU infoのエラーのみ引き起こすものが表示されます。
ユーザは、これらのエラーを無視してもかまいません。
パッケージの削除(unmerge)
"unmerge"するという行為は、ファイルシステムからインストールされたパッケージと関連するファイルを削除することです。それが再度マージされるまで、
パッケージの中のソフトウェアがシステムから取り除かれて、
もはや使われることはありません。
unmergeコマンド行引数に続けて削除対象となるパッケージ名を指定してemergeを呼び出すことで、パッケージの削除を行うことが可能です。
以下の例は、
ltraceの全てのインストールされたバージョンがまとめて削除されます:
コード表示 3.5 |
emerge unmerge ltrace
or
emerge unmerge dev-util/ltrace
|
Portageはまたunmergeするパッケージのバージョンを指定することも可能です。
その範囲は、= (正確なバージョン)、< (より小さい)、>
(より大きい)、<= (より小さいか同じ)、そして>=(より大きいか同じ)、
の使用によって指定します。以下の例は0.3.15と同じか、それより古いバージョンのすべてのltraceをunmergeします。
コード表示 3.6 |
emerge unmerge \<=dev-utils/ltrace-0.3.15
|
パッケージの範囲を指定するとき、>と<はシェルによって(リダイレクトとして)解釈されないように、エスケープすることが重要です。 また、例に示すようにパッケージのカテゴリー名を指定することも必要です。
パッケージの範囲を指定する方法のその他の例はemerge --helpのコマンドで知ることができます。
警告: パッケージのunmergeは危険です。ユーザがあらゆるコアパッケージを削除したならばシステムは機能停止するかもしれず、また様々なライブラリの削除もソフトウェアを機能停止にするかもしれません。Portageはコアパッケージや、
他のパッケージのための依存性を削除することに対し警告しません。
|
もしも実際にemergeプログラムによってインストールされたパッケージを削除する場合は、
どのパッケージが削除されるか正確に表示され、ユーザには指定された何秒間かキャンセルする余裕があります。この待機中にControl-Cを押すことでユーザは削除が開始される前にキャンセルできます。
一旦削除が開始したら、パッケージに属するファイル名の長いリストが表示されます。
これらのファイル名のうちいくつかはファイル名の左にフラグが表示されます。
これらのフラグ(!mtime、!empty、cfgpro )は、パッケージの削除が行われたにもかかわらず、なぜこのファイルは削除されなかったかについての原因を示唆しています。
ファイルシステムから正しく削除されたファイルはこれらの3つのフラグは表示されません。
フラグ!mtimeは、指定したバージョンのパッケージにおいて、インストール後にファイルが修正されていることを意味します。
これは誰かがこのファイルをインストール後に編集したか、
他のパッケージがこのファイルを後から上書きした事を意味しています。
これにより、昔インストールされていたバージョンを削除したせいで、重要不可欠なファイルも同時に削除されてしまう、という事態を恐れることなくパッケージの更新を行うことができます。
フラグ!emptyは、空でないディレクトリであるために、Portageが削除を拒否したことを意味します(複数のパッケージは頻繁に同じディレクトリに対する所有権を要求します)。
フラグcfgproは、設定ファイルの保護が働いたことを意味します。
これは、新しくインストールされたパッケージが、保護された設定ファイルに対する所有権を要求し、Portageがそのファイルを削除することを拒絶したことを意味しています。
警告: ファイルはインストールされた最後のパッケージによって所有されていると解釈されます。これはインストールの順序に依存していて、
実際のバージョン番号やリビジョン番号とは無関係である、ということです。
過去に古いパッケージによってインストールされたファイルであったとしても、最新のパッケージを削除しようとした際にはそのファイルを常に削除しようとするのです。
(ユーザが手動でそのファイルを修正しなかったと仮定します)。
|
System Update
Portageは、インストール済みのパッケージに対して、たった1つのコマンドによりアップグレードを行うことが可能です。
System Updateの特徴は、Gentooのコアデベロッパー達によって推奨されるバージョンへと「コア」パッケージを更新することです - そのバージョンとは、あらゆるGentoo Linuxシステムの運営に関して重要となりうるバージョンのことです。 System Updateは、システムの運営と維持にとって不可欠なパッケージであると、Portage profileに定義されているパッケージのみを更新します。
それ以外のパッケージの更新を行うことはありません。
システム更新を実行するためには、以下のようにタイプしてください:
コード表示 3.7 |
emerge --update system
|
Portageは、インストール済みのパッケージとバージョン、そして現行のPortage profileによって推奨される構成に基づいて、更新のためのコンパイルとインストールを行います。
ユーザはemerge --update systemの間に何がインストールされ、更新されるのかのリストを得るために、上記の例に対しても--pretend引数を使うことが可能です。
注意: みなさんはインストール作業中にベース(または"コア")パッケージをインストールするためにemerge systemを最初に実行したのに気がつくでしょう。emerge --update systemは、それらのベースパッケージを、最新の推奨されるバージョンに更新します。
|
World Update
Portageはまた、システムにとって不可欠ではないパッケージに対しても、たった1つのコマンドによりアップグレードを行うことが可能です。
Portageは、パッケージによって利用可能なバージョンが複数あって、衝突する可能性があるようなシステムにおいても、安全にアップグレードを行えるくらいの知性を備えています。
PortageのWorld Updateの特徴は以下の項目をチェックしていることです -
system profile、ブロックされたパッケージのリスト(package.mask)、world profile、そして、アップグレードが必要なパッケージが決定した時点での(バージョンの範囲も含めた)world profile内でのパッケージの依存関係。
パッケージは、新しいバージョンが存在するとき(そのパッケージがworld profileにリストアップされている場合に限ります)、もしくはworld profile内で依存関係にある場合にのみ、アップグレードの対象になります。
なお、そういったパッケージもしくはパッケージの特定のバージョンは、system profileやpackage.maskによってブロックすべきではありません。
アップグレードの対象となるのはどういったパッケージでしょうか。
Portageはまず、world profileに記述されたパッケージ全てを、ブロックされていない利用可能な最新バージョンへとアップグレードすることを試みます。
またPortageは、world profileに記述されているパッケージが依存しているパッケージを最新状態にアップグレードしようとします。ただし、それは「利用可能」で、「依存関係の範囲内のバージョン」で、かつsystem profileやpackage.maskによってブロックされていないという条件付での最新状態です。
また前の章の中で言及されているように、SLOTを考慮に入れられています。
他のディストリビューションや、Portage以外のパッケージングの手順に詳しいユーザは、どうしてPortageは単なるバージョンナンバーに基いた、シンプルな「隠された(blind)」パッケージの更新を行わないのか、と混乱するかもしれません(Gentoo1.0以前ではそうであったように)。
GentooのPortageツリーに含まれている多くのパッケージは多くのバージョンが利用できます。
より古い、もしくはより新しいパッケージは、それに依存しているソフトウェアにとっては互換性の無いものかもしれません。
他のパッケージが必要としているか否かを考慮しないまま、ライブラリやツールに「隠された」アップグレードを施してしまうことは、すぐに多くの難しい問題を引き起こすでしょう。
この問題を避けるために、Portageはアップグレードの際に細心の注意を払いますし、また、すべてのパッケージに対して、それぞれ個々のebuildで指定された依存性を考慮に入れようとするのです。
PortageのWorld Updateの心臓部はworld profileにあります。
通常開発者によって定義され、ユーザによってはほとんど触られることがないsystem profileとは違って、world profileはユーザが起こしたアクションにより間接的に生成されるものです。
world profileは、「お気に入りリスト("favorites list")」のようなものです。
emergeコマンドを通してユーザにより手動でインストールされたパッケージは/var/cache/edb/worldにあるworldファイルに記録されます。
Portageは、パッケージのインストールについて以下のように考えます。
「インストールを行ったということは、あなたはこのパッケージの更新についても少なからず関心があるはずだ」と。
worldファイルは1行につきカテゴリーとひとつのパッケージ名から成り、以下のように見えます:
コード表示 3.8 |
net-im/gaim
net-www/skipstone
net-www/galeon
app-editors/vim
app-text/ispell
net-mail/evolution
dev-util/ltrace
sys-apps/xfsprogs
=net-www/mozilla-0.9.8-r3
sys-apps/attr
sys-apps/dmapi
sys-kernel/linux-sources
sys-apps/acl
app-office/gnucash
app-cdr/xcdroast
|
この例でお見せしたファイル中のエントリのうち、ほとんど全てが、ユーザが主導で行ったマージの際にPortageによって自動的に加えられたものです。
新しいバージョンが利用できるならば、これらのパッケージはアップグレードされます。
注意:
時間を節約し、確実にお気に入りのパッケージを更新される状態にするには、手動でworldファイルを編集し、それらのパッケージのためにエントリを加えてください。
古いバージョンのPortageからアップグレードして使用しているようなユーザは、このファイルに慣れる必要があるかもしれません。
ここ最近のGentooのインストールやPortageによっては、インストール時にかなり密度の濃いworld profileが生成されてしまうのです。
|
mozillaパッケージ(=net-www/mozilla 0.9.8-r3)の行について注目してください。このエントリは、特定のバージョンに固定するためにユーザによって手動で変更されました。(このマニュアルのパッケージの削除(unmerge)セクションで述べられている)パッケージ範囲は、Portageに対して特定のバージョンの範囲内のみを考慮するように指定できます。
このエントリにより、Portageはmozilla-0.9.8-r3が唯一利用可能なバージョンであると考えるようになります。そして、いかなる理由があろうとWorld Updateによってこのパッケージが更新を試みられることが無い、ということになります。
下記のようにタイプすると全パッケージ更新が実行されます:
コード表示 3.9 |
emerge --update world
|
Portageは、worldファイルに記述されている全てのパッケージの更新を試み、それらのパッケージと依存関係にある全てのパッケージの更新も行います。
パッケージのアップグレードに必要とされる依存パッケージは、利用可能な最新状態へアップグレードされます。
worldにリストアップされていないパッケージ、またそれらのパッケージと依存関係がないパッケージに関しては更新が行われません。
警告: Portageは、設定ファイル保護機能によって保護されているディレクトリではファイルを上書きしません。
あなたは、現在の設定ファイルと、Portageが作成した新しいバージョンの違いを自分自身の手でマージする必要があります。
もし設定ファイルの更新を行わないならば、インストールされたソフトウェアは機能停止してしまうかもしれません。
Portageの設定の章で設定ファイル保護を見てください。
もしくは、emerge --help configをタイプしてください。更なる情報を得ることができます。 |
World Update中にどのパッケージが更新され、インストールされるかのリストを見るためには、
この章の前のセクションで説明した--pretend 引数を使うことができます。
注意: また、World UpdateはSystem Updateを自動的に実行します。
コアパッケージに対してはworldファイルを使用して動作を固定するようなことはできません。現在のPortage profileは常にその設定を上書きします。
|
World Updateの動作に関する一番おもしろい部分は、インストール済みの全てのソフトウェアをリコンパイルしたいと望んでいるようなユーザにはもってこいでしょう。
World Updateは、worldファイルに記述された全てのパッケージとその依存するパッケージを更新しようと試みます。よって、コマンドライン引数--emptytreeを使用することは、それらのパッケージとその依存関係全て(glibcは除く)のリコンパイルを強要することに他なりません。これは、コンパイラオプションを変更したい、もしくはUSEフラグを変更したい、そして、その変更を全てのソフトウェアに適用したいが、手動で全てのパッケージを再度マージするのは勘弁、といったユーザにとってはとても役立つことでしょう。worldファイルに、あなたが一般的に使っているアプリケーション全てを記述してください。そして、以下のようにタイプしてください:
コード表示 3.10 |
emerge --update world --emptytree
|
このコマンドに --pretend 引数を付け加えることで、再コンパイルされるパッケージの実行結果のリストを得ることができます。
Cleaning System
Portageは、同じバージョンのソフトウェアを複数共存してインストールすることができます。この機能を利用して、膨大な量のパッケージがGentooのPortage ツリーには存在します。(古いアプリケーションが、他のパッケージの新しいバージョンと互換性が無い場合などのための、後方互換性の維持のためです)
大抵、パッケージの新しいバージョンがインストールされる時、以前のパッケージは上書きされ、そして、残るのは全てシステムの動作に重要でない、いくつかのドキュメンテーション・ファイル等のファイルです。時間の経過と共に、この「ゴミ(cruft)」は、蓄積されて、貴重なディスク領域を圧迫していきます。
これを処理するために、Portageはユーザのシステムから以前のバージョンのパッケージを取り除く簡単な方法を提供します。 この機能は、emergeにcleanのオプションを記述します。つまり、以下のようにタイプして使用します:
次にemergeは削除されるパッケージのリビジョンとバージョン、残されるバージョンを表示し、そして、ユーザにControl-Cを押すことによってコマンドをキャンセルする時間が与えられます。典型的なシステムでは、怒涛のように動作が走り始めます - ファイルが消去されるか残されるかの長い長いリストを画面に表示しながら。
特に指定されない限り、Portageはworld(つまり、全てのインストール済みパッケージ)に対してcleanを行おうとします。あなたはオプションを指定してcleanの動作範囲を狭めることが可能です。そのオプションとは、world、system、パッケージ名のリスト、そしてこの章の「パッケージの削除(unmerge)」セクションで書かれているような、パッケージのバージョン範囲でも指定することが可能です。
パッケージのバージョンのうち、どのバージョンを除去すべきかを考えるとき、Portageはさまざまなprofile、他のインストール済みのパッケージとの依存関係、そしてSLOTに関して考慮します。全てのパッケージに関する依存関係が正しく定義されているならば、cleanは古いパッケージシステムを安全に取り除くことができ、あらゆる機能が損なわれることも、システムの機能が妨害されることもないはずです。
パッケージの除去(prune)
Portageはまた、パッケージの除去(prune)の機能があります。pruneの動作はcleanの安全でない形です。pruneは、最後にインストールされたバージョンを除いて、全てのパッケージの全てのバージョンを削除します。pruneはcleanが実行するチェックの多くを実行せず、そしてユーザのシステムから本質的な依存性を削除することができます。このオプションを使用すれば、システムを簡単に破壊することが可能なため、特に特別な状況下で無い限り使用は推奨されません。
pruneは、cleanと同じオプションを受け付けます。以下のようにタイプしてください:
Portageツリーの検索
GentooLinuxディストリビューションの心臓部を形成するPortageツリーは、途方も無く巨大です。 emergeコマンドには、クォートで囲った正規表現を検索文字列として受けつけ、検索を行う機能があります。正規表現は非常に扱いにくい野獣ですが、あなたが良い本を見つけ、正規表現を使うことに興味があるならば大変お薦めです。
多くの単純な検索は正確に表現をせずにすみます。以下は"gcc"という名前か、もしくは"gcc"は名前の一部という両方の簡単なパッケージの検索の例です:
コード表示 3.13 |
emerge search gcc
|
検索にマッチしたもの1件ずつに対して、パッケージの名称、最新の利用可能なバージョン、インストールされている最新版、そのホームページ、そしてパッケージに含まれているソフトウェアの説明をリスト表示します。
ヘルプの取得
emergeが持つ多くのオプションと、そのオプションがどういう動作をするのかについての情報は、以下のようにタイプすると表示されます:
役立つユーティリティ
Gentooユーザのみなさんによって作成されたいくつかのユーティリティが、あなたの人生をより楽チンなものにしてくれます。これらのユーティリティはGentoo Portageツリーの中のapp-admin/gentoolkitの中にあります。
-
etc-update : 環境変数EDITORに設定されたプログラムを使用して/etcファイルのマージングを支援するシェルスクリプト(正しく使わないと危険)
-
qpkg : パッケージ・データベース検索ツール
-
epm : RPMのような文法を持つもうひとつのパッケージ・データベース検索ツール
4.
マスクされたパッケージとは?
多くの人々は、emerge -u worldを実行したとき、なぜ新しくリリースされたはずのパッケージが含まれていないのかについて興味を持つようです。
その良い例がxfree-4.3.0(これを書いている時点のバージョン)です。
もしあなたがemerge syncに続いて、emerge -u worldを実行したら、xfreeは更新対象の候補として挙がってはいないでしょう。
これはなぜでしょうか?
その理由は、ある特定のパッケージは「マスク済み(masked)」としてマークされているからです。それはつまり、あなたが明示的にアクションを起こさない限り、それらのパッケージは自動的にアップグレードされることも、インストールされることも無いということです。
マスク済みパッケージのインストールを可能にする方法について知りたければ、
Gentoo Forumsの中にある
Masked Package
FAQを訪問してみてください。
|