Gentoo Linuxにおけるパッケージ管理について(実際のコマンド操作)
Gentoo Linuxのパッケージ管理はCLIのコマンド操作によって行う。ここでは、Portageに限らず、幾つかの追加パッケージによる操作についてもメモしておく。
Portage
emerge
パッケージの管理に関する操作(追加/削除/更新)を行うのは、パッケージ管理システムPortageのemergeコマンド。
(利用可能パッケージの情報を更新するが、高速な検索ができるeixは使用しない場合) $ sudo emerge --sync (パッケージの追加) $ sudo emerge -av [パッケージ名...] (インストール済みパッケージを利用可能な最新バージョンに更新) $ sudo emerge -avuD [world もしくは system もしくは 個別のパッケージ名...] (パッケージを削除) $ sudo emerge -aC [パッケージ名...] (依存されていないパッケージを消す) $ sudo emerge -a --depclean
-aオプションは、操作の前に確認をとるために付けている。
(2008/10/17)USEフラグを変更後、すぐに反映(変更されたパッケージを調べて再ビルド)するには--newuseオプションが便利。
emergeによるパッケージの削除に関して
-C(--unmerge)によるパッケージの削除に関して、依存関係のチェックは行われない。削除指定したものだけが消され、その結果どこかのパッケージの動作がおかしくなる可能性があったとしても、注意はされない。
system profileに含まれるパッケージを消そうとしたときに限り
!!! 'sys-apps/coreutils' is part of your system profile. !!! Unmerging it may be damaging to your system.
のように警告は出るものの、消すことはできてしまうので危ない。特に「sys-apps」内のものには注意。過去、sys-apps内のパッケージのパッケージ統合などによって、システムを最新の状態に更新しようとしたときにパッケージのブロック*1が発生し、正しいほうのパッケージを消す必要のあることが何度かあった。
パッケージの削除は、不要になっているパッケージを消す--depcleanをたまに行う程度で十分。
ebuildコマンド
Portageのebuildというコマンドを用いると、より細かいレベルで操作をすることができる。例えば
$ sudo ebuild [ebuildファイルの場所] merge
とすると通常のインストールの流れで処理と後始末が行われ、後ろのコマンド部分(上の例では「merge」)を変更することで、指定したところまでの処理を行う。
下の流れで続けてコマンドを実行すると、作業段階ごとに実行が止まる。
(1.展開・ビルドの後、作業ディレクトリの中で仮のインストール作業までを行う) $ sudo ebuild [ebuildファイルの場所] install (2.ビルドしたパッケージのディレクトリツリーをシステムへ組み込む) $ sudo ebuild [ebuildファイルの場所] qmerge (3.作業ディレクトリを削除) $ sudo ebuild [ebuildファイルの場所] clean
指定するコマンド(最後の引数)はマニュアルページに載っているが、これはebuildファイル内の処理段階に対応したものとなっている。「install」を最初に指定した場合はその前の「fetch」「unpack」「compile」がその前に実行されるが、いきなり「qmerge」を指定すると失敗する。
上の例では使用していないが、「unpack」を指定して止めておくと、ソースなどの展開、パッチ当てなどの後で停止するため、ebuildのテスト時にビルドエラーが出たりしたときにソース展開後の状態を作る*2のに役に立つかもしれない。
「digest」は「Gentoo Linuxにおけるパッケージ管理について(Overlay)」でも扱っているが、自作ebuildを使用するか既存のebuildを修正するときに使用する。
eix
以下はapp-portage/eixを使用する。
(利用可能パッケージの情報を更新し、高速な検索ができるeixのデータベースも更新) $ sudo eix-sync (パッケージ検索) $ eix [パッケージ名の正規表現] $ eix -e [一致するパッケージ名]
eixに-cオプションを付けると、出力がコンパクトになるため、多くの検索結果が出るときに見やすい。
eix用のデータベースは、eix-syncの中で行われる「emerge --sync」の更にその中で行われる「emerge --metadata」という処理によって生成されるPortageキャッシュ(/var/cache/edb/dep/以下)をもとにして生成されるが、このキャッシュを手動で再作成した場合、eix-syncの中で実行されるupdate-eixというコマンドを手動で実行する。
gentoolkit
以下はapp-portage/gentoolkitを使用する。
(動的リンクに失敗するパッケージを調べ、問題のあるパッケージを入れ直す)
$ sudo revdep-rebuild
(引数のパッケージ *に対して* 依存しているパッケージを調べる)
$ equery depends [パッケージ名]
(ソースパッケージ一時保存ディレクトリ(${DISTDIR})の不要なものを消す)
$ sudo eclean-dist
(tbz2パッケージ保存ディレクトリ(${PKGDIR})の不要なものを消す)
$ sudo eclean-pkgあるライブラリのバージョンが上がったとき、そのファイル名が変わってしまうことにより、突然システム上のプログラムやライブラリが動作しなくなるということが稀にある。そういったときにはrevdep-rebuildを実行し、そのライブラリを要求しているパッケージ側の実行ファイルやライブラリに埋め込まれた(動的リンクの)依存関係を修正するために、それらを再ビルドする。以前expatやD-BUSのライブラリでこのようなことがあり、大規模な再ビルドをする羽目になったことがある。
なお、tbz2パッケージに関してはここでは扱わない。
portage-utils
以下はapp-portage/portage-utilsを使用する。
(引数のパッケージからビルド時に要求しているパッケージを調べる) $ qdepends [パッケージ名] (引数のパッケージから実行時に要求しているパッケージを調べる) $ qdepends -r [パッケージ名] (引数のパッケージのインストール後にインストールされることを要求しているパッケージを調べる) $ qdepends -p [パッケージ名] (パッケージ内のファイルを一覧) $ qlist -e [パッケージ名] $ qlist [パッケージ名の正規表現] (ファイルの属するパッケージを調べる) $ qfile [ファイル名]
「qdepends -p」の依存関係はebuild中で「PDEPEND」と書かれているもの*3を調べ、これはプラグイン方式のアプリケーションのコア部分のパッケージのebuildの中に、最低限必須なプラグインを要求する用途や、必須にしたい追加データや、エディタの言語サポート追加などで使用されている。
この他にquse*4などもあるが、あまり使用することはないかもしれない。
関連記事:
- Gentoo Linuxにおけるパッケージ管理について(パッケージ、バージョンとその識別子)
- Gentoo Linuxにおけるパッケージ管理について(USEフラグ)
- Gentoo Linuxにおけるパッケージ管理について(Overlay)
- Gentoo Linuxにおけるパッケージ管理について(systemとworldのprofile、未インストールパッケージのインストール済みマーク付け)
- Gentoo Linux 2008.0 ライブCDのGUIインストーラでGUI構成のインストールをしてみた
- Gentoo Linuxにおけるパッケージ管理について(サービス、ランレベル、環境変数など)
- Gentoo Linuxにおけるパッケージ管理について(スロット、tbz2ファイル)
