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

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

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

Arch Linuxをメインに使うのをやめた理由

エッセイ ディストリビューション Gentoo Linux Arch Linux

私は、 Gentoo だけではなく Arch も使っています。

しかし、 Gentoo の方がメインで、 Arch をメインに使うのはやめました。PKGBUILDの管理が面倒なうえに、(Arch が愚直なまでの単純さを旨としているだけに、)カスタマイズすればするほど、きたなくなっていくので、苦痛になるんです。つまり、見るに見かねるんです。

しばしば Gentoo と Arch が似ていると言われ比較されていますが、全く異なる、対極にあるようなディストリビューションです。

  • Gentoo
    • 徹底的にカスタマイズ可能で、ユーザの意思を尊重する ("choice")
  • Arch
    • 徹底的に単純化(KISS, Arch Way)

双方の共通点をあえて挙げれば、いわゆるローリング・リリースのたぐい、つまり各パッケージのバージョンが常に更新され、ディストリビューション自体のリリースバージョンが(ほぼ)無いということくらいです。

パッケージ名に盛り込まざるをえない

Arch では、重複競合することを避けるようにパッケージに命名しています。

だから例えば、同名のソフトウェアが複数あったら、パッケージ名に何か付けて区別せざるをえません。

例えば、あるパッケージに GTK+ の2向けと3向けがあったときには、 パッケージ名に -gtk3 を付けて区別したりしています。

例えば、いわゆる開発版は主に AUR に投稿されていますが、パッケージ名に -git などの文字列が付けられて区別されています。

パッケージ名がきたないのは苦痛です。同じソフトウェアなのにパッケージ名が異なっていてしかも conflict するとか、苦痛です。シンプルではありません。

Gentoo では、カテゴリが異なっていればパッケージ名が同じでも支障がありません。 USE フラグやスロットの概念があるので、パッケージを変えなくても、例えば GTK+ 2 と 3、Qt 4 と 5 、あるいは Python 2 と 3 (以下略)は共通のパッケージになります。 また、「開発版」は 9999 のようなバージョニングをしているので、同じパッケージとして扱います。

Arch の特徴が、矛盾に

一言でいうと、 PKGBUILD の作成に手を出すと KISS でなくなるということです。

AUR

Arch でも、 AUR を用いればメインリポジトリ外のソフトウェアパッケージもインストール可能です。 しかしそれは、 パッケージマネージャの pacman の検索(pacman -Ss)ではかかりません。 pacmanでのリポジトリ検索に引っかからないものをインストールすることになります。インストールしたら、 pacman -Qs で(ローカルの)検索にはかかるようになります。 なぜなら、 AUR を利用したところで、手元でビルドした「野良パッケージ」をインストールしていることになるからです。 これは結局、 RedHat系においてはyumrpmDebian系においてはapt-getdpkgと似たようなもの(.rpm や .deb を手元でインストールするようなもの)です。つまり、リポジトリ検索と、インストール済みパッケージ管理が、別個に扱われてしまいます。

しかしそれが Gentoo だったら、パッケージマネージャひとつに統一されます。パッケージマネージャでビルドするのはメインリポジトリでも「オーバーレイ」でも同じだからです。

ABS

Arch でも、 既定の ./configure のオプションに難があれば、 ABSPKGBUILDをダウンロードして書き換えてmakepkgをやれば変えられます。 しかしそれはもう、リポジトリの範疇の外に出てしまいます。

Gentoo では通称「オーバーレイ」つまりリポジトリをつくって管理することで、パッケージマネージャで統一して管理可能です。

管理しにくい PKGBUILD

PKGBUILD は、バージョン番号も、ハッシュ値も、ファイル内にハードコーディングしています。そのため、バージョンアップ時にはファイルを精査して書き替えないといけません。

Gentooebuild システムは、

  • ファイル名からバージョン番号を読み取る(${PV})ので、かなり多くの場合にはファイルのリネームだけで済みます。
    • だから、パッケージ名やパッケージ番号やカテゴリをファイルパスから自動生成するようになっているのです、その方が合理的でシンプル。
  • ダウンロードするファイルのハッシュ値は、 ebuild ファイルではなく Manifest ファイルに格納します。
    • ebuild foo-12.3.ebuild manifest などと実行すれば Manifest が更新されます。

だから、Gentoo の方が管理が楽だと感じています。

自作パッケージの公開

Arch では、自作したPKGBUILDを AUR に投稿することは可能です。

しかし、まじめにやろうと思ったら、 AUR に関するメーリングリストに登録するなどして日々確認しておくべきです。 AUR に投稿したら、メンテナとしての責任は重くかかってきます。 嫌気が差したメンテナが管理放棄するという事態が起こったときには、 AUR 自体の質の低下ということになります。 メンテナがいないパッケージは日々出現し、メンテナ探しや、代わりがいないときには廃止という事態になります。

AUR の世界は、いわばAll or Nothing(投稿して全責任負うか、最初からやらないか)です。 何でもかんでもすべて AUR に投稿されているわけですから、AUR に投稿されているものの質をインストールする前に予測するには vote の票数をみるくらいです。

Gentoo では、自作「オーバーレイ」(リポジトリ)を公開すればよく、公式ウェブサイト上で紹介してもらうことも可能ですが任意です。 利用するユーザ側は、その「オーバーレイ」を利用するか否かを個別に判断するだけです。つまり、要るリポジトリだけを追加し、あれもこれも検索にかかるということにはなりません。 (その点では DebianRedHat 系と同じですが、Gentoo では、バイナリ配布をしないのが原則ですから、おかしなものがこっそり混ぜられているということはまずない、というか、やったら一目瞭然でバレます。)

まとめ

カスタマイズすると、Gentoo の方が管理が単純!

Why?

それは、そもそもカスタマイズすることが前提のディストリビューションだから、必要に迫られて管理しやすくしたということ

Arch の美点は、AUR や ABS や PKGBUILD を自作しないことでこそ、得られます