Portageの代わりにPaludisを使ってみよう。

PortageGentooシステムの中核をなすパッケージマネージャであり、Gentooの最大の魅力とも言われています。
つまりGentoo = Portage? いいえ!!

Gentooとは選択です❞

Gentooは選択なので、パッケージマネージャもまた選択の対象です。sys-apps/portageGentooの中核パッケージセット = system setには含まれていません。ではsystem setで要求されているのは何かと言うと、virtual/package-managerです。virtual/package-managerでは以下の3パッケージが列挙されており、いずれかがインストールされます。

残念ながら、portage以外は全てunstable扱いです。更に残念なことに、Portageに暗黙に依存しているパッケージ*1も存在するために、PortageGentooからはぎ取るのは結構困難ですね*2……。
でも普段はパッケージマネージャとしてPortage以外を使ったって全然問題ないのです。

Paludisを使おう。

そんなわけでPaludisを使いましょう。Paludisには以下のような特徴があります。

  • C++で書かれている。だからと言ってすごく速かったりはしませんが。
  • 複数のパッケージリポジトリを利用できる。Portageで言うところのOverlayの概念は必要ないということですね。
  • ebuildヒューリスティクスが色々と違う。
  • ebuild以外のビルドシステムにも対応している
  • 豊富なHookを利用できる。
  • 依存関係グラフを書いたり、既存のディレクトリをパッケージマネジメントに組み込んだりと言った面白楽しい機能。
  • その他いろいろ。

インストールするには。

emergeしましょう。それだけだ。eselect package-manager set paludisもしておくと良いかも。

Paludisの設定。

Paludis公式サイトのGetting Startedを読みましょう。
portage USEフラグを有効にすると一応Portage用の設定ファイルを読み込んで動作しますが、あまり当てにならないので自分でPaludis専用の設定ファイルを書くのが確実です。portage2paludisスクリプトを利用して自動作成し、説明を読みながら書き直すのが一番簡単かなと思います。

Paludisの利用。

Portageにおけるemergeに対応するのはcaveコマンドです。
(ついでに言えばpkgcoreではpmerge, pmaintです)
以下の例ではportage-2.2_alpha86、paludis-0.72.0、(ついでにpkgcore-0.7.7.8)を使用しています。

emerge --sync
cave sync
pmaint sync

caveのsyntaxルールはcave アクション 引数 (-オプション)という具合で、gitっぽい感じですね。
Paludisとpkgcoreはマルチリポジトリ対応なので、syncすると登録された全てのリポジトリが同期されます。

  • パッケージのインストール
emerge パッケージ名
cave resolve パッケージ名
pmerge パッケージ名

caveは対話的に動作しませんので、emergeの-a, --askや-p, --pretendに対応するオプションはありません。
オプション無しでcave resolveを実行するとemerge --pretend同様に実際には何もしません。
本当にアクションを実行する場合にはオプション-x, --executeを付けます(幾つかのアクションは-xオプションがなく、即時実行されます)
caveには -v, --verboseに対応するオプションは無く、常に饒舌です。

インストールにあたってUSE flagsやACCEPT_KEYWORDに修正が必要な場合にサジェストしてくれるのはいずれのパッケージマネージャも同じですが、総じてPortageのメッセージの方が親切でわかりやすいように思います。
Blockerがあった場合も解決方法をサジェストしてくれますが、Paludisでは-U, --permit-uninstallや-d, --permit-downgradeなどのオプションを使うとUpgrade時のBlockerを自動的に処理できたりします。Blocksパッケージを手動でアンインストールしなくて良いということですね。

  • パッケージのアンインストール
emerge -c パッケージ名
(emerge --depclean パッケージ名)
cave uninstall パッケージ名
cave resolve \!パッケージ名
pmerge --unmerge パッケージ名

resolveの引数に!パッケージ名とすると、インストールの逆の動作、つまりアンインストールします(シェルが"!"を解釈しないようにエスケープする必要があります)。
pmergeには依存関係を考慮して削除するオプションはありません。

  • インストール済みのシステムを最新に更新する。
emerge -uDN --with-bdeps=y world
(emerge --update --deep --newuse --with-bdeps=y world)
cave resolve world -B -ks -Sx -sx
pmerge --upgrade --deep --newuse --with-built-depends @system @world

emergeでの例は--with-bdeps=yなので、これはややパラノイア的ですね。またemergeの-N, --newuseオプションはebuild内部でのUSE Flag変更も検知します。Paludisとpkgcoreはそこまでしません。

caveの面白いオプションとしては、-R, --reinstall-scmというのがあります。SCMパッケージ(いわゆるlive ebuild)が最後にインストールされたのが一日以上前(-Rd)あるいは一週間以上前(-Rw)であれば、再インストールします。
caveにオプション-c, --completeを付けると-ks -Rw -Sa -sa -Bを付けたのと同じ意味になります。

PortageやPaludisと違い、pkgcoreでのworld setはsystem setを暗黙に含まないので、ターゲットに両方を列挙しています。

  • システムから不要なパッケージを削除する。
emerge -c
(emerge --depclean)
cave purge
pmerge --clean --with-built-depends

後で詳しく書きますが、PaludisではSLOT及びchoice dependencyの扱いがPortageやpkgcoreと違っています。なのでemerge --depcleanで消えるパッケージがcave purgeでは消えないことがしばしばあります。

  • モー!!
emerge --moo
cave moo

pkgcoreではLarry君に逢えませんね……。バグでしょうか。

マルチリポジトリ、さらに色々なリポジトリ

Paludisは複数リポジトリに対応しています。

Gentooユーザにとっては基本となるのはgentooリポジトリですね。おっと、Paludisの文書でも釘を刺されていますが*3gentooリポジトリPortageツリーなんて言ってはいけません。Portage以外でも使えるわけですから。gentooリポジトリgentoo-x86などと呼びましょう;-)

gentooリポジトリの設定例。

/etc/paludis/repositories/gentoo.conf

location = /usr/portage
sync = rsync://rsync.jp.gentoo.org/gentoo-portage
profiles = /usr/portage/profiles/default/linux/x86/10.0
distdir = /usr/portage/distfiles
format = e
names_cache = /var/cache/paludis/names

Gentooで利用できるebuildリポジトリはたくさんあります。それらもgentooリポジトリと同様に書くことができます。自分で書くのが面倒くさい場合には、app-portage/laymanから利用できるリポジトリに関しては、playmanコマンド(Paludisのruby-bindings USEフラグを有効にするとインストールされます)をlaymanの代わりに使えます。ただし、(p)laymanで提供されるリポジトリに関しては次に書くunavailable/repositoryリポジトリを使って利用する方法が推奨されています。

repositoryリポジトリとunavailableリポジトリ

unavailableリポジトリは「まだ設定されていないリポジトリ」の情報を保持するリポジトリです。
repositoryリポジトリはunavailableリポジトリの情報を元に「リポジトリ設定を自動構成するためのリポジトリ」です。
リポジトリ」がゲシュタルト崩壊しつつあります。

unavailableリポジトリの設定。

/etc/paludis/repositories/layman.conf

format = unavailable
name = layman
location = /var/db/paludis/repositories/layman
sync = tar+http://git.exherbo.org/layman_repositories.tar.bz2
importance = -100

Overlayの情報をダウンロードして利用するlaymanという名のunavailableリポジトリを作りました。

repositoryリポジトリの設定。

/etc/paludis/repositories/unavailable.conf

format = repository
config_filename = /etc/paludis/repositories/%{repository_template_name}.conf
config_template = /etc/paludis/repository.template

リポジトリ設定ファイルのテンプレートとして/etc/paludis/repository.templateも作ります。

format = %{repository_template_format}
location = /var/db/paludis/repositories/%{repository_template_name}
sync = %{repository_template_sync}
master_repository = gentoo

すると、普通のパッケージのようにインストールすることでリポジトリを追加できます。

cave resolve repository/betagarden -x -1

便利な副作用として、unavailableリポジトリは各リポジトリに含まれるパッケージ情報を含むので、まだインストールされていないリポジトリに含まれるパッケージもcaveコマンドで参照できるようになります。eix-remoteみたいな感じですね。

installed-unpackagedリポジトリ

cave importコマンドで、パッケージングがされていないディレクトリツリーをあたかもパッケージであるかのようにインストールできます。installed-unpackagedリポジトリはそのためのリポジトリです。
例えば、ごく一般的にソフトウェアをビルドして、

$ configure --prefix=/usr && make DESTDIR=/home/user/path install

出来上がったソフトウェアのディレクトリツリーをcave importします。

# cave import --location /home/user/path hoge/fuga

すると、/home/user/path以下のディレクトリ構成がhoge/fugaというパッケージとして/にインストールされ、Paludisで管理できるようになります。必要であればオプションで依存関係も定義できます。
空のディレクトリをcave importすれば、Portageのpackage.providedの代わりになりますね。

ebuildは簡単に書けるのが売りですが、ソフトウェアのビルド形態・配布形態によっては面倒なこともあります。そういう時にはかなり便利ではないでしょうか。ちなみに、Paludisはインストール時にファイルの衝突を検知しないので、システムを壊すようなディレクトリツリーをインストールしてしまわないように気を付けましょう……。

Paludisの提供する機能。

Paludisは、Portageでは外部ツールで提供されている機能を内蔵しています。

  • パッケージの詳細情報を表示します。
cave show パッケージ名
eix パッケージ名 (app-portage/eix)

showアクションのターゲットはパッケージ名だけでなく、setやrepositoryにもできます。

cave show repository/betagarden (betagardenリポジトリの情報を表示)
cave show @system (system set に含まれるパッケージを列挙)
  • パッケージに含まれるファイルを列挙します。
cave contents パッケージ名
qlist パッケージ名 (app-portage/portage-utils)
equery files パッケージ名 (app-portage/gentoolkit)
  • ファイルがどのパッケージに含まれているのか示します。
cave owner ファイル
qfile ファイル (app-portage/portage-utils)
equery belongs ファイル (app-portage/gentoolkit)
  • ライブラリのsoname変更で壊れたパッケージをインストールしなおす。
cave fix-linkage
revdep-rebuild (app-portage/gentoolkit)

ちなみに、pkgcoreではpqueryというコマンドでパッケージその他の情報を表示でき、これも非常に強力です。

外部ツールとの連携とか。

VDB*4Portageと互換性があるので、app-portage/eixやapp-portage/gentoolkit, app-portage/portage-utilsなどに含まれるユーティリティも一部は利用できます。ただし多くのコマンドがPortageの設定ファイルやログファイルを元に情報を表示するので、正しい結果が得られないことがあります。

非互換部分。

Paludisは自身の扱うファイル/ディレクトリのownerがpaludisbuild:paludisbuildであった方が色々と幸せですが、Portageやpkgcoreと混ぜて使うとパーミッションが変わってしまいます。まあ混ぜなきゃ良いんだよ。

  • worldファイルの扱い。

Portageでは、ユーザがsetをインストールするとworld_setsファイルに追加されます。特殊なset(@preserved-rebuildなど)はemergeしてもworld_setsには追加されません。
Paludisでは、cave resolve setしてsetをインストールするとworldファイルにsetを追加します。また、unavailableリポジトリを利用してリポジトリをインストールすると、それもworldに追加されます。いずれの場合も、Portageとの互換性は破壊されます。

worldファイルに記述されるパッケージ情報には、SLOTを含めることができます。

emerge --noreplace sys-kernel/gentoo-sources:3.2.1-r1

cave update-worldコマンドの引数となるターゲットはSLOT情報を含んではいけないので、以下はエラーになります。

cave update-world sys-kernel/gentoo-sources:3.2.1-r1

しかしPaludis自体はworldに記述されたSLOT情報を正しく認識します。ですから必要ならば直接worldを編集すれば良いですね。
pkgcoreはworldに書かれたSLOT情報を無視します。

Paludisでは、複数SLOTが存在するパッケージに対して依存元がSLOTを明示していない場合、全てのSLOTが必要であると解釈されます。例えばバージョン違いの複数のsys-kernel/gentoo-sourcesをインストールしている場合、各バージョンに応じたSLOTで分けられていますが、virtual/linux-sourcesがどのSLOTを必要としているかは不明なので、全てのSLOTが保持されます = cave purgeで削除されません。同様に、worldに記録されているパッケージも、SLOTが明記されていなければ、全てのSLOTが保持されます。

Portageの場合は依存SLOTが明示されていない場合は最新のSLOTのみを残します。

choice dependencyとはebuild

RDEPEND="|| (
	    category/pkg1
	    category/pkg2
	    ....

のように書かれている依存関係で、列挙されているうちのいずれかがインストールされれば依存関係を満たします。Portageの場合、もっともリストの先頭に近いパッケージのみが保持され、他は(別の依存関係に組み込まれていなければ)--depcleanで消えます。しかしPaludisでは列挙されているいずれのパッケージも削除されません。こちらはちょっと理屈と合わない気もしますけど、よくわかりませんでした。誰か説明してくれるとうれしいです。

  • VDBの非互換。

VDBは概ね互換性がありますが、保存されるenvirionment.gzには相違点があります。Paludisとpkgcoreは非互換で、Paludisでインストールしたパッケージをpkgcoreでアンインストールしたりするとエラーになります(その逆は大丈夫です)。また、Portage <-> pkgcore, Portage <-> Paludisの相互運用は問題ないようです。

まとめ。

Paludisを使ってみると、PortageGentooの特徴/魅力のごく一部分だということがわかります。Gentooの特徴といえば第一にパッケージマネジメントについて挙げる方が多いと思いますが、その魅力のほとんどはPMS*5ebuild*6、そしてgentooリポジトリの特徴であり、Portageに限定されたものではないのです。Portageを使わなくてもGentooGentooだよ!!

それともうひとつ、今気付いたのですが、Paludisを入れておくと万が一Portageが壊れてしまった時にとても役に立ちますね。これでもうPythonを壊してしまっても大丈夫というわけです。でもVDBが壊れたらダメなものはダメなんだけど*7

ということでみんなもPaludisを使ってみませんか。
Paludisだけ使っているとGentoo本家へのBug Report時にちょっと困っちゃうんですけどね……。

*1:sys-devel/gcc-configとか

*2:実際にPortageを削除してしまったらどうなるかもいずれ試します

*3:The main Gentoo repository, sometimes annoyingly called 'the Portage tree'

*4:/var/db/pkg: インストール済みパッケージのデータベース

*5:Package Management Specification app-doc/pms

*6:man 5 ebuild

*7:If you deleted /var/db/pkg by accident, you're pretty much screwed. So don't do that, and be more careful next time. If you deleted /var/db/pkg on purpose, please install OS X and stop pestering us.