読者です 読者をやめる 読者になる 読者になる

解き放たれしソフトウェア

GNU/LinuxなどFLOSSについて書いてみるつもり

【Gentoo】パッケージの指定方法

例えば、Portage パッケージマネージャのコマンドである emerge でソフトウェアパッケージをインストールするとします。 その際に、どのパッケージをインストールするかを指定するわけですが、

  • 同じパッケージ名が複数あるときは、ソフトウェアカテゴリも含めて指定する必要がある
  • 特定のバージョンをインストールしたいときは、バージョン番号も含めて指定する必要がある
  • Gentoo にはほかに、「スロット」という概念がある

といったことも知っておく必要があります。

カテゴリも指定

カテゴリ名/パッケージ名 (${CATEGORY}/${PN}) という構造になっています。

例えば Debian Almquist shell (DASH)をインストールしたいとします。

しかし、パッケージ名が dash であるパッケージは現在のところ2つあって、Emacs のライブラリにも dash があります。

$ eix -e dash
* app-emacs/dash
     Available versions:  (~)2.12.0 (~)2.12.1
     Homepage:            https://github.com/magnars/dash.el
     Description:         A modern list library for Emacs

* app-shells/dash
     Available versions:  0.5.7.4 (~)0.5.8.1-r2 0.5.8.2 {libedit static}
     Homepage:            http://gondor.apana.org.au/~herbert/dash/
     Description:         DASH is a direct descendant of the NetBSD version of ash (the Almquist SHell) and is POSIX compliant

Found 2 matches

こうしたときには、カテゴリ名も指定して、 emerge app-shells/dash のように実行します。

他のディストリビューションと異なり、Gentooではこのような構造になっているため、パッケージ名そのものを長くしなくても、カテゴリによって同名のソフトウェアを区別することが可能です。

バージョンも指定

パッケージ名の後にバージョンをつなげます。 ただし、emergeのような場面では、パッケージ名の先に = を付けます

しかも、シェルでは=特殊文字であるため、エスケープする必要があります

そうすると例えば emerge \=app-shells/dash-0.5.8.1-r2emerge \=zsh-5.2 のようになります。 (言うまでもなく、バックスラッシュではなくシングルクオーテーションでエスケープしてもかまいません。)

ちなみに、バージョン番号に -r2 のようにリビジョン番号が付いているものがありますが、これは ebuild ファイルのリビジョン番号であって、ソフトウェア本体のリビジョン番号ではありません

世の中にはとんでもないバージョニングをするソフトウェアもありますから、 openssl-0.9.8z_p8 のようにパッチ番号もありますし、 git-sources-4.4_rc5 のようにRC(Release Candidate)のものもあります。このように複雑なバージョン番号は、ハイフンで延ばすのではなく、アンダーバーで伸ばしています。 つまり、バージョン番号の後のハイフンからはリビジョン番号が繋がることに決まっています。

ちなみに、999999999999 のようなバージョン番号の ebuild ファイルもありますが、これは development版です。 つまり常に最新のもので、実際のソフトウェアの中身は書き換えられていき固定されていません。 Gentooでは便宜上、必ず最大になるようなバージョン番号を付ける必要があって、9999 のようなバージョン番号がGentoo側で付けられています。

スロット番号

ソフトウェアの中には、複数のバージョンを、同時にインストールしておくことが可能な場合や、便宜上強引にでも共存しないといけない事情がある場合や、dependency を特定するためなどの便宜上でバージョン番号だけでは困る場合などがあります。

そこでGentooでは、「スロット」という概念も用いています。

例えば、 GUI ツールキットである GTK+ (GIMP Toolkit+) だと

$ eix -e gtk+
* x11-libs/gtk+
     Available versions:  
     (1)    1.2.10-r13
     (2)    2.24.28-r1 (~)2.24.29
     (3)    3.16.7 (~)3.18.5 (~)3.18.6

のように、メジャーバージョンの、1系統、2系統、3系統があります。 そしてそれぞれにスロット番号を付けていて、1系と2系と3系の共存が可能になっています。 (かりにスロットの概念がなかったら、インストールする度に上書きしてしまいますものね。)

例えば、Gentooでは Linux カーネルも、ビルド済バイナリではなくソースコードで配布していますが、(原則として)自動的にビルドしてはくれず、自力でビルドしろということになっています。(実際にカーネルのコンフィグは複雑で多様なので、genkernelのようなツールを使うなり、自力でやらざるをえません。)

したがって、 例えばsys-kernel/gentoo-sourcesのようなパッケージをインストールすると、インストールされるのはあくまでもソースコードです。

ですから、カーネルソースコードはバージョンごとに別々に保存をしておくことが可能ですし、実際にその必要もありますから、カーネルバージョンごとにスロット番号も付けられています。(複数カーネルイメージをインストールしておいて、バージョンアップ時などでも確実に移行したいですよね。その他さまざまな事情で、複数カーネルイメージをインストールすることが一般的によくあります。)

そして、スロット番号を指定してパッケージをインストールすることが可能で、例えば emerge gtk+:2 だとか emerge gentoo-sources:4.3.2 のように、: に続いてスロット番号を指定します。

スロット化のいささか強引な例

例えば python はメジャーバージョンアップごとに使用が変更されて混乱が起こっていることで知られています。とりわけ 2系から3系に上がった時の互換性の無さは大変なものです。 現在のところ、

$ eix -e python
* dev-lang/python
     Available versions:  
     (2.7)  2.7.10-r1 (~)2.7.10-r3 (~)2.7.10-r4 (~)2.7.11
     (3.3)  3.3.5-r1 (~)3.3.5-r2 (~)3.3.5-r5(3.3/3.3m)
     (3.4)  3.4.3 (~)3.4.3-r2 (~)3.4.3-r5(3.4/3.4m)
     (3.5)  (~)3.5.0-r1 (~)3.5.0-r4(3.5/3.5m) (~)3.5.1(3.5/3.5m)

のようになっていますが、つまりスロットの概念によって、複数の系統を共存させることが可能になっています。 この共存のために、強引にディレクトリ構造を構成して、バージョンごとにライブラリも処理したり、スクリプトを実行するための wrapper も用意しています。

それではシェル上で python と実行したら、どのバージョンが実行されるのでしょうか。 それは、 eselect で設定します。

$ eselect python list
Available Python interpreters:
  [1]   python2.7
  [2]   python3.4 *
  [3]   python3.5
$ sudo eselect python set 3
$ eselect python list
Available Python interpreters:
  [1]   python2.7
  [2]   python3.4
  [3]   python3.5 *

同じように、コンパイラGCC も、スロット番号で管理されており、共存が可能です。 そして GCC の場合は eselect ではなく gcc-config で設定しますので注意が必要です。


以上はあくまでも、emerge などのパッケージマネージャや、 equeryeix のようなツールなどで活用する範囲での、概略的な説明です。

実際には、リポジトリ(オーバーレイ)を複数インストールしたときはリポジトリ名の指定や、 ebuild ファイルを自力で書いたときなどにはバージョン範囲の指定など、さらにたくさんの記法があります。


この投稿は、 Gentoo Advent Calendar 2015 - Qiita 15日めの記事です。