Gentoo Linuxを約12年ぶりに使った際のメモ(2020年11月)

久しぶりにGentooを使う機会があったので、以前(最後の使用は2008年)から変わっていることや新しく分かったことなどをメモする。今回は常用することにはならず、OSのインストール関係でのメモが主となる。今後もしばらくは使う予定はない。

stage3のバリエーション
インストール環境
パッケージ管理関係

make.conf関係
ライセンスの許可
~amd64などのインストール
x86_64におけるmultilib
パッケージビルド時の改善された挙動

lldでビルド時間短縮を図る
バイナリが落とせるパッケージ
ClangはGCCを置き換えられるか?
genkernelはinitrd生成のみでの使用も可

stage3のバリエーション

OSをインストールするために使われる最低限のファイル群を書庫ファイルにまとめた “stage3” イメージは

無印 (OpenRC)
systemd
その他 (no multilibなど)

と分かれており、x86_64の “no multilib” はx86(32bit)のライブラリがシステム上で共存できず、完全な64ビット環境となる。これは用途を選ぶかもしれない。

他のディストリで既にsystemdのコマンドを使ったことがあって、なおかつOpenRCに興味がないのであれば、他のディストリと設定方法の共通しているsystemdでもよいが、他のディストリにおいてはインストーラが設定してくれるような所を手動で設定する場面が発生する上、Gentooでsystemdを使うために必要な設定もあるため、それらを別途Gentoo Wikiなどで確認することになる。systemdについては別ディストリ向けの情報も役に立つことがある(今回はArch Linux用のsystemd設定の一部を参考にした)。

今回はsystemd用を使ったが、Gentooのインストールに不慣れな場合は(Gentooの公式ドキュメントが想定している)OpenRCを使う方法が無難な印象がある。

なお、eselect profile ...で扱うプロファイルについてもsystemd用は別に分かれている。

インストール環境

過去に実機にGentooをインストールした時(2005年の年末頃)はGentooのインストールCDから起動してハンドブックの内容を事前に紙にメモしたものを見ながら作業していたが、今回はインストールCDイメージは使わず、Ubuntu 20.10上でパーティション(今回は/用と/var用を用意した)をフォーマットしてからstage3を展開してハンドブックを直接Webブラウザで見ながら作業した。

事前にフォーマットを行っていた関係でハンドブックとは作業順の異なる部分があった。既に動いているLinuxシステムのGUI環境からのchrootによるインストールは、Web上のドキュメントを見ながら設定ファイルの編集をしたり、パッケージのビルドをできるときに少しずつ進めたり、必要に応じてメモや実行したコマンドなどをファイルに保存したりなど、作業の自由度が上がるので、やりやすかった。

パッケージ管理関係

make.conf関係

パッケージのビルドに関する設定を記述するmake.confは/etc/portageの下に置く。GENTOO_MIRRORSで国内ミラーを複数記述しておく。

インストール可能パッケージの情報や各パッケージの作成処理を含む “Portage tree” の既定の場所やファイルダウンロード先、バイナリパッケージ保存先の既定値も/varの下の全く新しい場所に変わっている。

# was /usr/portage, see also /etc/portage/repos.conf/gentoo.conf
PORTDIR="/var/db/repos/gentoo"

# was /usr/portage/distfiles
DISTDIR="/var/cache/distfiles"

# was /usr/portage/packages
PKGDIR="/var/cache/binpkgs"

ライセンスの許可

ソフトウェアのライセンスが自由でない場合に、それをインストールするためには許可するパッケージについての記述を/etc/portage/package.licenseに追加する必要が出るようになっている。

身近な例はカーネルのバイナリファームウェア。

このライセンス用ファイルに限らず、Would you like to add these changes to your config files? [Yes/No]で設定ファイルに変更を適用することもやってくれるのだが、ファイル名が変わるので、自動で上書きされるわけではない。

~amd64などのインストール

package.keywordsというファイル名ではなく/etc/portage/package.accept_keywords/以下のファイルに記述する形になっている。

x86_64におけるmultilib

x86_32用にビルドする必要のあるパッケージがあるときには/etc/portage/package.useで各パッケージにabi_x86_32を付けることが要求されるが、これも適用後の設定ファイルを書き出す機能があるので、個別に手動で記述する必要はない。

Wineなどの32bitアプリケーションを使うことを考えている場合、インストールの初期の段階でpackage.useを編集して32bit版ライブラリのビルドを行うようにしておいたほうがインストール時間が短縮できる。

手元の環境では、後からmultilibのための記述を追加した結果、ビルドに時間のかかるLLVMとClangを余計に再ビルドするはめになったため、次回stage3からインストールする機会があった場合は気をつけたい(LLVMやClangが入ったstage3があれば良かったのだが…)。

32bit版のMesaを入れようとするとLLVMのライブラリも32bit版が必要になるのがGentooではつらい。

パッケージビルド時の改善された挙動

いつから変更されたのかは不明だが、幾つか気付いた改善点。

複数パッケージインストール時のソースファイルのダウンロード処理はパッケージのビルド中にバックグラウンドで行え、多数のパッケージをインストールする際に時間を効率よく使える
CMakeを使用したプロジェクトは高速なNinjaバックエンドが選択されてビルド時間が短縮される
ビルド用ツリーの最終的な使用領域サイズとシステムへインストールされるサイズがシステムへのインストール時に表示される

lldでビルド時間短縮を図る

2020年11月時点では、最も高速なリンカ実装のlldがパッケージとしてインストール可能なものの標準では使われていない。ビルド時間短縮に役立つので、sys-devel/lldをインストール後にmake.confのLDに指定する。

LD="/usr/bin/ld.lld"

なお、同月時点ではClangにはdefault-lldというUSEフラグがある。

バイナリが落とせるパッケージ

あまり自分ではビルドしたくない、一部の大型パッケージを並べておく。

sys-kernel/gentoo-kernel-bin
app-office/libreoffice-bin
www-client/firefox-bin
www-client/google-chrome
dev-java/openjdk-jre-bin
dev-lang/rust-bin
mail-client/thunderbird-bin

dev-lang/rustについては、自分でビルドするのが標準のようだが、ビルドには7-8GiBの空き領域が必要で時間もかなり要するということで、個人的にはソースからビルドするメリットが見出だせない。

他にPyPy3のバイナリを提供するパッケージもあったのだが、今回は動かなかった。

ClangはGCCを置き換えられるか?

今回は、早期にClang (10.0.1)をインストールした上で残りのパッケージをClangでビルドしてみることにした。

LLVMとClang本体それぞれにかなりビルド時間がかかった上、Clangでビルド中のパッケージでビルドエラーが出たり、GCC(9.3.0-r1, stage3のバイナリを使用した)でビルドしないと依存した別のパッケージがエラーになるといった謎の不具合に複数遭遇したため、無難にいきたいならまだGCCを使ったほうがよさそう。

dev-lang/spidermonkey-60.5.2_p0-r4: GCCでビルドしないと別パッケージが “undefined reference” のリンク時エラーを出す (https://bugs.gentoo.org/681656)
sys-auth/polkit-0.116-r1: GCCでビルドしないとビルドエラー
sys-boot/efibootmgr-16: 上に同じ
mail-mta/nullmailer-2.2-r1: 上に同じ
media-sound/pulseaudio-13.0: 上に同じ
dev-libs/elfutils-0.181: 上に同じ
dev-libs/libgcrypt-1.8.6: 最適化フラグ関係の処理がうまく動作せずにビルド失敗