Portageの代わりにPaludisを使ってみよう。
PortageはGentooシステムの中核をなすパッケージマネージャであり、Gentooの最大の魅力とも言われています。
つまりGentoo = Portage? いいえ!!
❝Gentooとは選択です❞
Gentooは選択なので、パッケージマネージャもまた選択の対象です。sys-apps/portageはGentooの中核パッケージセット = system setには含まれていません。ではsystem setで要求されているのは何かと言うと、virtual/package-managerです。virtual/package-managerでは以下の3パッケージが列挙されており、いずれかがインストールされます。
- sys-apps/portage
- sys-apps/paludis
- sys-apps/pkgcore
残念ながら、portage以外は全てunstable扱いです。更に残念なことに、Portageに暗黙に依存しているパッケージ*1も存在するために、PortageをGentooからはぎ取るのは結構困難ですね*2……。
でも普段はパッケージマネージャとしてPortage以外を使ったって全然問題ないのです。
Paludisを使おう。
そんなわけでPaludisを使いましょう。Paludisには以下のような特徴があります。
インストールするには。
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の文書でも釘を刺されていますが*3、gentooリポジトリを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*4はPortageと互換性があるので、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情報を無視します。
- SLOT、choice dependency。
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を使ってみると、PortageはGentooの特徴/魅力のごく一部分だということがわかります。Gentooの特徴といえば第一にパッケージマネジメントについて挙げる方が多いと思いますが、その魅力のほとんどはPMS*5とebuild*6、そしてgentooリポジトリの特徴であり、Portageに限定されたものではないのです。Portageを使わなくてもGentooはGentooだよ!!
それともうひとつ、今気付いたのですが、Paludisを入れておくと万が一Portageが壊れてしまった時にとても役に立ちますね。これでもうPythonを壊してしまっても大丈夫というわけです。でもVDBが壊れたらダメなものはダメなんだけど*7。
ということでみんなもPaludisを使ってみませんか。
Paludisだけ使っているとGentoo本家へのBug Report時にちょっと困っちゃうんですけどね……。
*2:実際にPortageを削除してしまったらどうなるかもいずれ試します
*3:The main Gentoo repository, sometimes annoyingly called 'the Portage tree'
*4:/var/db/pkg: インストール済みパッケージのデータベース
*5:Package Management Specification app-doc/pms
*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.