試験運用中なLinux備忘録・旧記事

はてなダイアリーで公開していた2007年5月-2015年3月の記事を保存しています。

Gentoo Linuxにおけるパッケージ管理について(パッケージ、バージョンとその識別子)

Gentoo Linuxにおけるパッケージ管理についての幾つかの内容を下に書いているが、これは覚え書きに過ぎず、内容も恐らく不十分なため、
http://www.gentoo.org/doc/ja/portage-manual.xml
も参照。

Gentoo Linuxのパッケージ

Portageツリーと同期

Gentoo Linuxにおける「パッケージ」は、ebuildと呼ばれるbashスクリプトベースのファイル群とパッチなどの関連ファイルとをまとめたディレクトリツリー(Portageツリー)のデータをもとに、Portageというパッケージ管理ツールを用いて追加/更新/削除を行う。
PortageツリーはGentooのミラーサーバと同期することで最新の状態に更新する。同期を行うべきペースは多くても1日に1回で、実際にはそこまで頻繁には行わない。
Portageツリーの既定の場所は/usr/portage/だが、/etc/make.conf*1の変数PORTDIRで変更することもできる。

パッケージは原則として手元でビルドしてインストールする

機能サポートの有無などを「USEフラグ」の指定によって細かくユーザ好みにカスタマイズできるようになっている関係か、パッケージのビルドは原則として手元で行うことになる*2。また、そのため、コンパイルを行うものは、そのオプションも自由に変更でき*3-march=オプションやその他最適化オプションをいじることで、性能もわずかに向上する場合がある。ただし、危険なオプションを入れることは推奨できず、性能向上を期待しすぎるのもよくない。
パッケージによっては、問題の原因となると分かっている最適化オプションをフィルタしている場合がある。*4
関連URL:

インストールの流れとしては

  1. 必要な(ソースなどの)ファイルをダウンロード
  2. ダウンロードしたファイルをビルド用の一時ディレクトリに展開して、自動で設定やビルドを行う
  3. インストール先の一時ディレクトリにインストールイメージを作成し、システム上に組み込み(「マージ」する)、インストール情報を保存する

という感じで、ビルドから一時ディレクトリへのインストールの間は、sandboxという仕組みによってシステム上に対する書き込みはブロックされる。*5
なお、ダウンロードされるファイルは既定では/usr/portage/distfiles/以下に保存され、/etc/make.conf内の変数DISTDIRで変更することができる。

バイナリ提供のパッケージも一部存在する

自分でビルドしなくても利用できる一部のパッケージ(「-bin」で終わる名前のもの)もあるが、(ゲームとJava関係を除くと)数は少なく、OpenOffice.orgMozilla製品など。それ以外には、ソース非公開なもの(Adobe製品、VMware製品、VirtualBoxのバイナリ版、一部のグラフィックドライバなど)もビルド作業はない。*6
(2008/10/17)この他、OSをライブCDのGUIインストーラでインストールしたときに、Gentoo公式のビルド済みパッケージをある程度入れることができる。また、非公式なパッケージ配布サーバからビルド済みパッケージを取ってきて使用することができる仕組みも用意されている。

ユーザが実際に使用するのはemergeコマンド

実際の操作としてはPortageに含まれるemergeコマンドを使用し、Portageツリーの更新*7からパッケージの各種操作までを行える。

パッケージのバージョンとリビジョン

パッケージそのものが持つバージョンと、ebuild自体の持つリビジョンとがあり

[バージョン]-r[リビジョン]

の形で全体のバージョンが表される。バージョン部分が同一の場合には、リビジョン番号の大きいほうが新しいとみなされる。
リビジョンが上がるときには、ソースに対して新しいパッチが追加されるような場合もあるが、依存関係の記述が調整された場合などには、リビジョンを上げる前に問題が起きていなくても*8、パッケージの無意味な再ビルドを行わなくてはならないこともある。*9
/etc/make.conf内の変数FEATURESに「ccache」を含めるとccacheを使用することもできるが、一度ビルドしたものを再コンパイルするというケースは(普通にパッケージのインストールや更新を行う使い方においては)実際には少なく、余計に処理が増えるだけという恐れもあり、おすすめはできない。
関連記事:

関連URL:

パッケージの識別子(atom)

上のバージョン/リビジョンの前に分野名とパッケージ名、バージョンの大小を含めて、「どの分野の何というパッケージのどのバージョン/リビジョンか」を識別するための文字列(パッケージatom)を使用することがある。これに等号/不等号、チルダ(任意のリビジョンを指定)、アスタリスク記号(任意のバージョン値の代わり)*10とを必要に応じて組み合わせて表現する。

>=sys-apps/groff-1.19 - 「sys-apps」の分野にある「groff」パッケージのバージョン1.19以上
=sys-devel/gcc-4.2* - 「sys-devel」の分野にある「gcc」パッケージのバージョン4.2(の後ろは任意)
~sys-apps/coreutils-6.12 - 「sys-apps」の分野にある「coreutils」パッケージのバージョン6.12(リビジョンは任意で「6.12-r1」「6.12-r2」などの全てが指定される)
app-emulation/wine - 「app-emulation」の分野にある「wine」パッケージの任意のバージョン

この形式は、emergeで操作(追加/更新/削除)するパッケージ(とそのバージョン)の他、/etc/portage/以下の「package.」で始まる名前のファイル(ここでは扱わない)に対しても使われる。
バージョン部分を省略した場合、全てのバージョンを示すが、emergeによるパッケージインストール時には、利用可能な最新版が選択される。
また、ebuildファイルの中では、依存関係の記述で「!app-emulation/virtualbox-ose」のように「!」が付く書き方があり、これはそのパッケージがインストールされていない必要があることを示す。

関連記事:

*1:makeの設定ファイルではなく、GentooPortageが使用する設定ファイル

*2:インストール作業そのものは、ebuildファイルに書かれた処理が自動で行われる形

*3:/etc/make.conf内の変数CFLAGS/CXXFLAGS

*4:${PORTDIR}/eclass/flag-o-matic.eclass内の関数を使用している

*5:ACCESS VIOLATION」とメッセージが出てビルドは失敗する・これはebuild側の問題で、ebuildの作成者がシステムへの書き込み要求を回避するようにビルドシステムへの引数やビルド設定ファイルを微調整しなくてはならない

*6:グラフィックドライバの場合、カーネルモジュール部分はビルドすることになる

*7:emerge --sync」を実行する・ただし、高速なパッケージ検索ツールeixを使用する場合はeix-syncの実行時に行われる

*8:たまたま、依存関係の記述が不足していた必須パッケージがインストールされていたという場合など

*9:ebuild作成側の話として、そのような場合は、本来はebuildの内容を変更してもリビジョンを上げる必要はないらしい

*10:リビジョン番号に対して「[バージョン]-r*」と書くことはできず、その場合は任意のリビジョンを指定するためにチルダ記号を使用する