Portage と Paludis と Pkgcore と

Gentoo は、 choice の世界である

パッケージマネージャ(Package Management System;PMS)も、リポジトリも、 選べなければならない。

選択と責任の世界である。 言い換えれば、選べないところには、決定も責任も無い。 これは、人生にも、デモクラシーにも言える。 (だが日本社会にはデモクラシーが無いので、こうした、決定と責任という発想に乏しいのだが)

ともかく、 Gentoo の PMS には、デフォルトである Portage のほかに、 Paludis と Pkgcore がある

歴史的経緯から、Gentoo と Portage は密接不可分だ。 FreeBSDにあるような Ports システムに触発されてPortage が創られ、次いで Gentoo が始められた

もしこれが、 Debian や RedHat や Ubuntu ならばいい。むしろPMSが一つしか無いほうが解り易い。あるいは Arch の人たちは KISS なので、わざわざ簡単でなくするような実装は許せないだろう(笑

しかし、choice を標榜する Gentoo において、Portage しか選択肢がないのは自己矛盾、二律背反である。 だからGentoo では、PMS に必要な基準の策定をしたうえで、それを満たした複数の PMS の用意をして、選べるようにしてある。 Portage、Paludis、Pkgcore の3つである


Portage

Portage には、いくつもの特徴がある(あった)

Python というスクリプト言語で書かれている

Pros:

ソースコードそのままで動作をするので、見たままである

また、Python のような類は、書き易く、ライブラリが多く容易にimportして増やせる(Perl, Ruby, Haskell にしてもそうだが)

Cons:

逐一インタプリトするのでオーバーヘッドが生じ、遅くて、リソースの累積消費量も多い

dependency などの計算が、意外と、粗雑だ

Pros:

本当は矛盾するパッケージ同士も、しれっとインストールをして共存をさせられてしまうことがある

Cons:

システムが壊れるかもしれない

機能が継ぎ接ぎで、足りない機能は独立ツールになっている

錯綜している。自己完結をしていない。 ソースコードが煩雑だ

マルチリポジトリ対応ではなかった

最近の ver 2.2.16 で初めてマルチリポジトリに対応。 それまでは、所謂 Overley で、つまり、 Portage ツリー(= gentoo リポジトリ)を上書きするような形で、他のリポジトリの利用をしていた。 リポジトリの choice が前提でないのは、 Gentoo として間違えている

Git や SVN 等の sync に対応をしていなかった

これも 2.2.15 以前のことだが。 Portage ツリーは rsync をし、 layman は Git 等に対応しており overlay をそれで sync している


Paludis も Pkgcore も、プログラミング言語が異なるし、マルチリポジトリ対応だし、Git等に対応をしている

Paludis

コマンド名は cave

Portage に対して極めて批判的

C++ で書かれている

C で無いのは、 C++ の方が楽に書けるからであるようだ

dependency の計算が、 Portage よりも正確

杓子定規だとも頑固だとも神経質だとも言えるが

クセがとてもある。 例えば ebuild ファイルに

と書いてあると、「先に書いてある方が優先的に求められている」という解釈をする。 そのため、foobar/haun がインストール済であっても、 「foobar/hogehoge が無い」という指摘をしてくる。回避をするにはオプションで指定する必要がある

(ちなみに Portage でもクセがあり、未インストールならば黙って、先に書いてある方をインストール。だが、インストール後は、どれか満たしていればスルーをし、指摘をしない)

例えばXfce のインストールでも、Portage ならば

または

なんておかしなことをせねば、 GNOME の通知デーモンが勝手にインストールされてしまう。 https://wiki.gentoo.org/wiki/Xfce

これがPaludis では、

となる

ただこのように、 Paludis ではオプションの -F, --favour-matching, -A, --avoid-matching を使いこなさないと、 こういった dependency で思うようにいかない。 Portage のように勝手にやってはくれず、「指示待ち」の杓子定規なタイプである

fail-safe な設計である

例えば、 -x オプションを付けなければ pretend (dry-run) になる。 (Portage ならば、 emerge にオプションを付けなければ黙って勝手にインストール作業をしてしまうのに対し)

ちなみに、 -a (--ask)は無い(おそらく、ろくに確かめもせずに Enter を押してから「アーッ」ってなって Ctrl-C を押したトラウマがあるからだろう)

デフォルトで大体は、無難な処理をしてくれる。 world の更新が、 cave resolve -x world のコマンドラインだけで概ね成功(余計なオプション付けずに)

「自分で確かめろ」「根拠の無い信用をするな」「絶対安全なんて在り得ないんだ」という 家訓でもあるかの如きで、Portage のトラウマから始まっているようだ

初期設定は手間取る。よく解っていないと使い始められない

玄人専用のオプションは多数 あり、やれるバリエーションは大変に多い

cave コマンドで全て可能

cave foobar みたいな形式で、全てが cave で始まる (Portage ならば、 emerge, emaint, equery 等々の複数のコマンドがあるのに対し)

しかしそのため、man cave-hoge のようにせねばならない、 cave haun --help のようにせねばならない。そういうデメリットも在る

処理中に黙りこまない

Portage だとしばらく黙りこくることがあって怖いのに対し、 cave resolve は、quietの設定をしても configureやmakeの出力を抑えるだけで、 cave 自体が何をしているかは常に表示

SCM (VCS; live) 版の定期的な再インストールが可能

-R オプションで、一定期間経過後したものだけ再インストール、ということが可能

とはいえ Portage で app-portage/smart-live-rebuild を用いた方が便利だが (だって、更新内容があるか調べてくれる。期間基準ではない)

Pkgcore

Pkgcore は、操作方法が概ね Portage 互換。 Paludis と異なり、 Portage に喧嘩を売る気は無い

Python と C で書かれている

コマンド名が Portage 似

Portage の コマンドの最初の"e" を "p"に変えると、そのまま Pkgcore だ

例えば、Portage の emerge は、 Pkgcore の pmerge だ

オプションも Portage 互換

ただ、 emerge では dependency の関係を表示させるのに必要だった -vt オプションが、 Pkgcore では要らない。もとより表示をする

Portage の設定を自動読込み

Portageを適切に設定済であれば、かなりの確率で、追加設定不要。 設定を自動インポート

設定を書き換えることも可能。 但し、そのときの設定ファイルの書き方は、 Windowsの9xや3.1では一般的だったのと同じ ini ファイル形式。この点は(GNU/Linux界隈では)とても珍しい


Paludis は、2015-03-03 現在の最新バージョンは 2.0.0 (stable) と、 2.2.0 (unstable) である。 マニュアル自体は大部で読むのに苦労をする。だが、ウェブサイトに書いてあることはまだ足りないので、不明な点がたくさん残る。とりあえずウェブサイトを読む限り、「文句があるなら Mac 使え」というらしい(笑

Pkgcore は、0.8.6 (unstable) では旧すぎるので、 9999 (no keyword, development ver.) でないと使い物にならない。 ウェブ上の情報が足りない。足りないが、概ね Portage と操作性が共通なのでなんとなく使える。それがいささか危なっかしいのだが

PMSの変更にあたっては、 app-admin/eselect-package-manager もインストールをすると良い。 また、 python-updater, haskell-updater, perl-cleaner は、Paludis や Pkgcore に対応済

ちなみに、Paludis や Pkgcore の対応をしていないソフトウェアや、Portage も無いといけないソフトウェアが少なくないので、Portage のアンインストールは困難

Paludis や Pkgcore に関する日本語の記事がかなり少ないので、 とりあえず本稿を書いてみた。 まだまだ足りないが。 Paludis は、奥の深さからすると、書けることがたくさんある。 Pkgcore は、私には未知なことが多い

Audacious 3.6 の日語訳を出稿した

タイトル通りだが。来る Audacious version 3.6 のための日語訳を出稿した

今月末には翻訳原稿〆切りで、3.6 が正式リリースになるはずだ。 未訳を無くしたので、まだらに英語が残っているという状態は無くなるだろうと見込んでいる(駆け込みでコードが増えたりしなければ……)

Audacious は、高機能・多機能で、高速で、GUIの、世界有数の音楽プレイヤだろう。 例えばどこぞの、利用者に無断で音楽ライブラリを生成する、生成しないと動かない、というプレイヤではない

iTunesの真似をしたRhythmBox等は使いづらい。 WinAmpの真似をしたXMMSの真似をしたのが Audaciousだが(笑)。私は昔、WinAmpも利用していたが、当時は WinAmp ですら遅いとは思っていたものだ。だが、WinAmpに送金し、ライセンス買っていた(笑)。当時の私は、SCMPXを主に利用していた。 今も一部には、foobar派やLilith派も現存しているだろうか。していると思いたい(笑

さて、動画プレイヤならば、同様に簡単かつ高機能なGUIものがあるが。例えば VLC や MPC だとか。 実際に、VLCは対応フォーマットが多いので音楽プレイヤとしても役に立つけどね

Audacious は bs2b と SoX Resampler があるので好きだ

ソフトウェアをマニュアルインストールする際のコツ

ソフトウェアをアーカイブ(tarball)から手作業でGNU/Linuxにインストールする際には、コツがある

通常は /usr/local/ 以下にインストールする。そうすることで、パッケージマネージャ等でインストールされたものと区別して管理する。 e.g. ./configure --prefix=/usr/local のように指定してビルドする

ただし、ビルド済のバイナリをインストールするならば、 /opt/ 以下にインストールする



なんかいかがわしいと思うのだが SlimBoatウェブブラウザ というものを、インストールしたいらしい。

tarball の中味はビルド済のバイナリのブロブなので、/opt/に slimboat ディレクトリを造ってインストールすれば宜しい。

sudo cp slimboat_amd64.tar.xz /opt/
cd /opt
sudo tar xvfJ slimboat_amd64.tar.xz
sudo rm slimboat_amd64.tar.xz

ホームディレクトリ以下にインストールしておきながら、 global な .desktop を作成するのは止めるべきだ。 ローカルユーザとグローバルがごっちゃになっているから

反対にあくまでもホームディレクトリ以下にインストールするならば、 .desktop にせよ menu にせよ、ローカルユーザの領域で作成せねばおかしい ちなみに、menu は ~/.config/menus/ に、 .desktop は ~/.local/share/applications/ に置く


さて、この失敗事案の主因は異なるところに在る

起動用スクリプト slimboat.sh の中味が特殊だからだ。 具体的に言うと、当該ディレクトリを開いた状態で実行することが前提になっている (ちなみにこれを解読するには、 dirname や basename というコマンドを知らねばならない)

slimboat.sh
#!/bin/sh
appname=`basename $0 | sed s,\.sh$,,`

dirname=`dirname $0`
tmp="${dirname#?}"

if [ "${dirname%$tmp}" != "/" ]; then
dirname=$PWD/$dirname
fi
LD_LIBRARY_PATH=$dirname/libs
export LD_LIBRARY_PATH
export QT_PLUGIN_PATH=
$dirname/$appname "$@"

だから、メニューから実行しようとしたらエラーで起動し得ない

なお、もともとが、メニューからの起動に失敗したときにはエラー内容がメッセージボックスで出たりは しない ので、 黙ってうんともすんとも言わないままになる

そこで例えば、

exec.sh
#!/bin/sh

export LD_LIBRARY_PATH="/opt/slimboat/libs"
export QT_PLUGIN_PATH=
export PATH="/opt/slimboat:${PATH}"
slimboat "$@"

というスクリプトファイルを /opt/slimboat/ に作成する (勿論、 sudo chmod +x exec.sh もする)

slimboat.desktop
[Desktop Entry]
Name=SlimBoat
Name[ja]=SlimBoat
GenericName=Slimboat Web Browser
GenericName[ja]=ウェブブラウザ Slimboat
Comment=Browse the World Wide Web
Comment[ja]=ウェブブラウジングをします
Exec=/opt/slimboat/exec.sh %u
Terminal=false
Type=Application
Icon=slimboat
Categories=Application;Qt;Network;WebBrowser;
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;image/gif;image/jpeg;image/png;
StartupNotify=true

アイコンの画像は、

sudo cp slimboat.png /usr/share/icons/

ちなみにローカルユーザ領域のアイコン置場は無論、 ~/.local/share/icons/

wjn's repos' info.

  Japenese , English