Gentoo、バイナリ版を公開
(gentoo.org)- Gentooはソースベースのディストリビューションという性格を維持しつつ、低速なハードウェアやインストールの容易さのために、公式のバイナリパッケージのダウンロードと直接インストールを提供する
- 提供範囲はアーキテクチャごとに異なり、amd64とarm64では20GB超のパッケージと、毎日更新されるGentoo stableパッケージを利用できる
- 新しいstageインストールにはバイナリリポジトリ設定が含まれており、既存のインストールでは
/etc/portage/binrepos.conf/に設定ファイルを追加して利用できる - 公式パッケージは署名可能なGPKG形式で、検証に失敗するとインストールは拒否されるが、デフォルト設定では互換性のために署名なしのXPAKも許可される場合がある
- プロファイルのデフォルトと異なるUSE flagの組み合わせを使うとバイナリパッケージをそのまま使いにくくなるため、必要な部分はローカルコンパイルと混在させて運用する必要がある
Gentooが公式バイナリパッケージを提供
- Gentooは、Portageが以前から対応していたバイナリパッケージ機能を、公式ダウンロードと直接インストールの形で提供する
- 低速なハードウェアでの作業時間を減らし、インストール全体と更新の利便性を高めることが目的
- 従来どおりソースベースのディストリビューションとして残り、ソースビルドとバイナリパッケージを併用できる
アーキテクチャ別の提供範囲
- 大半のアーキテクチャではコアシステムと週次更新の範囲に限定される
- amd64とarm64ではより広いパッケージセットを提供する
- ミラーには20GB超のパッケージが置かれる
- LibreOffice、KDE Plasma、Gnome、Dockerなどが含まれる
- Gentoo stableパッケージは毎日更新される
インストール環境ごとの設定方法
- 既存のGentooインストールでバイナリパッケージを使うには、
/etc/portage/binrepos.conf/に設定ファイルを作成する必要がある- 一般的な手順はBinary package quickstartを参照できる
- より詳細な設定はbinary package guideにまとめられている
- 新しいstageベースのインストールには
/etc/portage/binrepos.conf/gentoobinhost.confがすでに含まれている- 必要なら
src-uriをローカルミラーの該当ディレクトリURIに変更できる - 更新例は
emerge -uDNavg @world
- 必要なら
amd64とarm64のビルド基準
amd64/binpackages/17.1/x86-64配下のバイナリパッケージは次の設定でコンパイルされるCFLAGS="-march=x86-64 -mtune=generic -O2 -pipe"- すべてのamd64 / x86-64マシンで動作する
- amd64パッケージのUSE flag設定とバージョンは安定パッケージのプロファイルに対応する
amd64/17.1/nomultilibamd64/17.1/desktop/plasma/systemdamd64/17.1/desktop/gnome/systemd
arm64/binpackages/17.0/arm64配下のパッケージは次の設定でコンパイルされるCFLAGS="-O2 -pipe"- すべてのarm64 / AArch64マシンで動作する
- arm64パッケージのUSE flag設定とバージョンも安定パッケージのプロファイルに合わせられる
arm64/17.0arm64/17.0/desktop/plasma/systemdarm64/17.0/desktop/gnome/systemd
- CPUごとの最適化が必要なら、これまでどおり自分でコンパイルする必要がある
他アーキテクチャとstage連携
- 他のアーキテクチャやABIのバイナリパッケージホスティングはstageビルドと連動している
- ほぼすべてのstageについて、そのstageの内容と設定のみを含むバイナリパッケージホスティングが提供される
- その範囲には
gccまたはclangコンパイラと完全なビルドツールチェーンが含まれる - 現時点でこの範囲をさらに拡張する予定はない
署名と検証方式
- 公式バイナリパッケージには、stageと同じキーによる暗号学的署名が適用される
- 署名キー情報はGentoo signaturesで確認できる
- Portageは2種類のバイナリパッケージ形式を扱う
- XPAK: 従来形式で、署名をサポートしない
- GPKG: 新形式で、暗号学的署名をサポートする
- 公式GentooバイナリパッケージはすべてGPKG形式
- GPKGパッケージは署名を検証する
- 検証に失敗するとインストールは拒否される
- デフォルト設定では、古いバイナリパッケージとの互換性のために署名なしのXPAKパッケージもインストールされる可能性がある
- 検証済み署名を必須にするには、
make.confにFEATURES="binpkg-request-signature"を設定する必要がある- この場合はGPKGパッケージのみ利用できる
署名エラーと自作パッケージ
- 署名を検証できないというエラーが出た場合は、rootでGentoo Trust Tool
getutoを実行できる- コマンド例は
getuto - Portageに必要なGentoo Release Engineering keyringを設定する
- コマンド例は
make.confでFEATURES="binpkg-request-signature"が有効になっている場合、バイナリパッケージのダウンロード前にgetutoが自動で呼び出される- キーの更新と失効を取得するための動作
- 自作のバイナリパッケージはPortageに拒否される場合がある
FEATURES="binpkg-request-signature"の副作用- 自作パッケージには署名キーを設定し、
/etc/portage/gnupgのアンカーがそのキーを信頼するようにする必要がある
ミラー、プロファイル、USE flagの制約
- ダウンロードが遅い場合は、University of Oregonではなくローカルミラーの利用が推奨される
/etc/portage/binrepos.confのURIを修正すればよい- 暗号学的署名のおかげでローカルミラーを使っても安全
- プロファイルのデフォルトと異なるUSE flagの組み合わせを使うと、そのバイナリパッケージは利用できない
- Portageはバイナリパッケージとローカルコンパイルしたパッケージを混在して使える
- Gentooは完全なバイナリ専用インストールを目指してはいない
- merged-usrシステムでもパッケージを利用できる
- 問題があればバグとして報告すべき
- 他の旧バージョンまたは新バージョンのプロファイルとは併用できない
src-uriパスに17.1のようなプロファイルバージョンが含まれる理由- 新しいプロファイルバージョンが出ると、別の新しいパッケージディレクトリが提供される
~amd64と問題報告
~amd64バイナリパッケージはまだ提供予定がない- 提供には大量の再ビルドが必要
- 提供するとしても技術的理由で別URIが必要になる
- テスト用パッケージが必要なら、stableをできるだけ維持しつつ、
package.accept_keywordsにローカルで追加する方式が推奨される- 多くのバイナリパッケージは引き続き利用できる
- 残りは自分でコンパイルする必要がある
- Portageや特定パッケージに問題があれば、IRC、フォーラム、メーリングリストで助言を求めるか、バグを提出できる
- バイナリパッケージ対応は一定期間テストされてきたが、利用者が増えればエッジケースが発生する可能性がある
1件のコメント
Hacker News のコメント
まず前提として、私は Gentoo の筋金入りのファンです。
Gentoo の魅力は、すべてをソースからコンパイルすることにあるのではなく、優れたドキュメントと最小限の障壁で、ほぼどんなハードウェアにも自分の望むものをインストールできる自由があることにあります。
2008年製のノートPCで Enlightenment + OpenRC + NetworkManager を使いたければ Gentoo を入れればいいし、スマート冷蔵庫のルートファイルシステムに ZFS を使いたくても Gentoo なら可能です。
新しいノートPCで素の Gnome + SystemD を使いたい場合でも可能です。
バイナリパッケージを提供するという決定は、ユーザーに より多くの選択肢を与えるものであり、他のディストリビューションが選択の自由を減らしてきたこととは対照的です。
Debian は「ユニバーサルオペレーティングシステム」と言いながらも 32ビット x86 のサポートを終了し、代替 init システムもインストールは可能ですがかなり面倒です。
一方 Gentoo は、17個以上の stage 3 tarball と 35個の eselect プロファイルから選べるようにしています。
個人的には、すべてをソースからコンパイルすることとその柔軟性を楽しんでおり、最新のハードウェアではまったく苦になりません。
同意しないなら、新しいバイナリパッケージをインストールすればよいのです。
Gentoo のセールスポイントは Portage ではなく、常に 柔軟性とコミュニティでした。
リリースチームの会議で、いつか特定されていない将来に 32ビット x86 向けの インストーラーとカーネルサポートがなくなる可能性が高い、という結論に至った、というほうが近いです。
現在はどちらも依然として提供され、完全にサポートされています。
特に 32ビット/64ビットのマルチアーキテクチャを引き続き使えるため、32ビット x86 ソフトウェアも実行できます。
誰もがすべてをサポートしたいと思っていますが、結局ディストリビューションとしてセキュリティとメンテナンスを保証するには、管理できるリソースに限りがあります。
何かは必ず諦めなければなりません。
どんな Linux ディストリビューションでも望むものをインストールすることはできますが、本当にサポートしていると言える範囲は常に メンテナーの人数に制限されます。
https://buildd.debian.org/status/package.php?p=base-files&su...
Debian のあまり知られていないアーキテクチャの大半を、定期インストールスナップショットとともに直接メンテナンスしているので分かります。
https://cdimage.debian.org/cdimage/ports/snapshots/
Debian には i386 と amd64 の両方に Hurd ポートもあります。
musl や clang のプロファイルを使ったわけでもありません。
これが第一印象なので、Gentoo やその下流フォークがインストーラーを提供しない限り、検討するつもりはありません。
近いうちに Solus OS / Solus Linux を入れてみる予定ですが、パッケージマネージャーの第一印象が良く、nix や guix のような方式ではないものの、再現可能だと主張しています。
Gentoo の大きな魅力は、個人的には Portage です。
単なるビルド環境や依存関係管理以上のものを提供しています。
Ebuilds、つまり Gentoo のパッケージは、ビルド時のさまざまな例外的状況に対処してくれる優れたツールと Eclass に支えられています。
Ebuild を開発するのは実際のソフトウェアプロジェクトをやっているような感覚で、公式リポジトリにないパッケージを試したい人に向いています。
ちょうど ebuild テスト用の非特権 chroot を管理するツールも公開したところです。
今回の変更で Gentoo は多くの人にとってより近づきやすくなるでしょうが、私には合わなさそうです。
私のビルド設定、たとえば CFLAGS は公式バイナリと絶対に合わないでしょうから、結局使わないと思います。
Gentoo を運用環境で使うとき、使っていないソフトウェアとの機能や統合を外すことが セキュリティ態勢の重要な部分になりました。
ただし、常にバイナリを作る専用のビルドホストを用意していたものの、Gentoo のバイナリサポートはあまり良くありませんでした。
コンパイル済みの成果物を HTTP や NFS で署名なしに提供する程度がすべてでした。
新しいパッケージ形式に暗号学的検証が入るとのことで、本当に期待しています。
内部専用の配布であっても、本来最初からあるべき機能です。
binrepo を別途構成したくはないが、特に クロスコンパイルが絡むとなおさらで、それでも既存の Portage 設定とカスタム ebuild は再利用したい、という場合に有用です。
ChromeOS は bazel を使って一時的な chroot の中で ebuild を実行します。
https://chromium.googlesource.com/chromiumos/bazel/+/refs/he...
こうすることで、宣言されていない依存関係が使われないことを保証できます。
それでも plasma 関連パッケージは共通バイナリを使うように上書きするスクリプトを作ってみたい誘惑があります。
速度が重要なものは自分でビルドし、GUI まわりのパッケージはバイナリで受け取れば、ビルド時間を大幅に節約できそうです。
デメリットもそれほど大きくなさそうです。
私の サンドボックスプロジェクトで、そういうものを本当に切実に探していました。
Gentooという概念について何を言うにせよ、17歳のときにソフトウェアのパッケージング、分散コンパイル、コンパイル時最適化の細部、Linuxカーネルの最適化を学ぶ過程は本当に楽しかった。
記憶ではコミュニティ文書もかなり良かった。
自分が送ったパッチのいくつかは、今でも一部のリリースのどこかに残っているかもしれない。
ただ、SlackwareマシンがGentooマシンと同じくらい速く動くのを見て初めて、あらゆる調整や最適化、最新ソフトウェアにはそこまでの価値がないのだと気づいた。
特定のアプリ、たとえばレンダーファームや暗号通貨マイナーのようなものでは、カスタムコンパイルや調整が役に立つことはあるだろうが、ゲームはどのディストリビューションでも同じFPSが出た。
昔は最小公倍数的な対象に合わせてコンパイルすると、MMXやSSEすら含まれず、CPUに縛られる一部のアルゴリズムでは大きな差が出ることがあった。
ただし、実行時にCPU機能を検出して最適なバージョンを実行することも常に可能だったので、コンパイル時に機能を選ぶことだけが唯一の方法ではなかった。
その後AMD Opteronが登場し、全員が新しいベースラインに乗った。
amd64向けにコンパイルするということは、また特定のCPUを意味するようになり、当時はまだそれ以上に新しい命令は存在しなかった。
今ではAMD64に複数のレベル[1]があり、SIMDのような特定の処理では重要になることがある。
もっと平凡でよく遭遇する例として、v2で追加されたpopcntはbitsetのようなものでは単体では有用だが、プログラム全体の性能では、自分のプロジェクト群ではv1とv3の差をほとんど測定できなかった。
ゲームの場合、おそらくバイナリ専用で、すでに最小公倍数に合わせてコンパイルされていたか、実行時の機能選択を使っていた可能性が高い。
それに、ほとんどはどうせGPUボトルネックだったはずだ。
[1] https://en.wikipedia.org/wiki/X86-64#Microarchitecture_level...
数年前には、いったいなぜそうしていたのか、Gentooシステムをコンパイルして細かく調整するために、コンピュータの時間と自分の時間を何時間も、何日も無駄にしていた。
どうせ翌日に新しく届いたUbuntu CDをインストールするためにフォーマットするつもりだったのに。
かつて自分でカーネルをコンパイルし、今はしていない人たちは、少なくとも少しの間でもそういうことを経験したからこそ、今の実力者になっている面がある。
やってみた後で、今はやらないのが合理的なのだ。
「もっと賢ければ、そんなことに時間を無駄にしなかったのに」と言ったり、初めて見る人がそう受け取ったりするのは正しくない。
結局疲れ果ててArchに移り、壊れたパッケージと常に格闘しなくても、ほとんど同じものを得られた。
それでも、ランダムに起きる低レベルの問題を扱いながら得た知識は、今でも使い続けている。
それでも多くを学んだ。
最近はLinuxが自分のスーパーパワーのように感じる。
OS、VM、コンテナ、Nix-shell、WSL2はすべてLinuxだ。
どんなコマンドラインに放り込まれても、ある程度はBSDも含めて、気楽に感じるし問題を解ける。
Gentooと過ごした楽しい時間がそこへ導いてくれたのだと思いたい。
CentOSではコマンドラインプレーヤーのmpg123を1つ使うだけでもX全体のインストールを求められたが、Gentooではmpg123のX統合をオフにできた。
フラグはその上に載ったボーナスだった。
今はDebianをインストールし、毎日使うプログラムをいくつか入れて終わりにしている。
別のマシンでも自分の構成を20分以内に再現できる。
2000年代初頭にGentooを長く使っていて、Linuxマシン全般について知っていることのほとんどをその経験から学んだ。
USEフラグで興味深かったのは、あるパッケージが別のライブラリやパッケージと特定の統合を持っているという事実そのものを知れたことだった。
SQLite3バイナリがreadlineサポートなしでリンクされると同じようには動作しないと気づき、readlineが全体として何なのかを理解するようになった。
他のLinuxシステムでは常に含まれているように見える、数多くのライブラリについて同じことが繰り返された。
自分の人生の適切な時期に出会った、本当に価値ある学習ツールだった。
ちょっと妙な気分になる
多くのコメントが、Gentooを使ったことがある、あるいは昔使っていたと言っている
でも自分は今でもデイリードライバーとサーバーの主力として使っている
何が違って、Gentooが自分にとって最高なのか気になる
それにバイナリパッケージは有効にしないつもり
GPD Win 4、corebootを載せたPixelbook、NAS、VPSなど、すべてのデバイスでGentooを動かしている
理由はこうだと思う
SystemDが欲しければ使えばいいし、OpenRCが欲しければすぐに使える
Gentooでは安全で居心地よく感じる
Linuxで自分が最も重視している自由を、Gentooは常に尊重してくれると分かっているからだ
Gentooはゲームブックのようなものだ
SystemD + Gnome + PulseAudio + バイナリパッケージを使いたければ可能だし、OpenRC + Hyprland + Pipewire + netifrcの代わりにNetworkManagerを使いたくても可能
Gentooはすべてをコンパイルするディストリビューションではなく、すべてを選ぶディストリビューションだ
今回の発表は自分には関係ないが、ユーザーにより多くの選択肢を与えるものだ
Gentooも良いが、NixOSシステム管理者として生きるほうが、Gentooシステム管理者よりずっと楽だ
答えてもらっても反論したいわけではなく、純粋に気になっている
自分の場合、Gentooが合わなかった理由を言うと、個人サーバーは運用しておらず、職場ではクラウドサーバーを使っている
おそらくUbuntuベースかAWS流のものだろうが、カーネルをコンパイルしたりはしない
デスクトップでは10年以上前に、友人から「自分のハードウェア向けにコンパイルされるから速くなるはず」と説得されてGentooを試した
インストールして動かすのに多くの時間を無駄にしたが、自分がやるどの作業でも普通のUbuntuより目に見えて速いわけではなく、設定時間だけが余計にかかった
だから捨てた
また、よく聞く「Gentooを設定しながら本当に多くを学んだ」も、自分の場合は嘘だった
たいていの人と同じようにレシピに従い、理解していないフラグを設定し、設定ファイルをいじっただけなので、安全に言えば何も学べなかった
ただ手順を踏んだだけだ
もちろん自分の経験はそうだったという話だ
正確には分からないが、自分も20年目使っている
毎週触るデイリードライバーやサーバーではなく、ずっと前に設定して、その後ずっと動き続けてきた機器のことだ
年に数回しかログインしない程度のシステムを指している
最初の「運用」システムを作ったときにGentooをやめた
人々が使い始め、毎日や毎週ログインする理由がもうないという意味で「完成」した状態だった
セキュリティアップデートは続けたかったし、ごくまれに新機能のために新しいパッケージが必要になることはあったが、基本的には安定したシステムが欲しかった
Gentooはこの用途にはひどく向いていなかった
個人デスクトップでも毎週アップデートしていたが、ほぼ毎回emergeのビルド失敗があり、数か月アップデートしないこともあるシステムならさらに悪いはずだ
それでDebianに移り、良かった
特にunattended upgradesが良く、最終的にすべてのマシンをDebianへ移した
Gentooを使っているなら、毎週手を入れないマシンもあるのか、どれくらいの頻度でアップデートしているのか、アップデートを終えるのにどれくらい頻繁に手動介入が必要なのか気になる
あまりに少なすぎるし、15年遅い
15年以上前にGentooからFreeBSDへ移った理由の一つは、Gentooではすべてをコンパイルする必要があり、FreeBSDはバイナリパッケージを提供していたからだ
今ではそれほど重要ではないかもしれないが、CPUコアが1つでRAMが1GBだった時代には、状況を一変させる差だった
Gentooを長く使ったあと、数年間macOSへ移り、そのときGentoo prefixを使ったが、Homebrewよりはるかに優れていた
ほぼ10年前に、macOS上のGentoo prefixで上流のllvmが動くようにするパッチを追加した [1]
GSoCの再会イベントで、自分に管理者権限を与えたがっている人にようやく会えたが、最後まで進まなかった
彼はその作業が複雑になるだろうとすでに警告していた
prefixにもバイナリが必要だとずっと言っていた
MacでGentoo prefixがHomebrewと同じくらい簡単にパッケージをインストールできていたらどうなっていたか、想像してしまう
悲しいが、Gentooは技術的に優れたオープンソースプロジェクトであっても、基本的なエンドユーザーの利便性を無視し、良い管理体制がなければ、劣った解決策に打ち勝って生き残ることはできないという良い例だ
opensolaris/illumosも事実上、延命装置に頼る状態になった理由はこれと似ていると思う
責任者たちはエリート主義を乗り越えられず、コミュニティ参加のためには、カーネルビルドに理解不能なmakefile/shellスパゲッティ100層より単純な何かが必要だ、という判断を下せなかった
[1] https://github.com/fishman/timebomb-gentoo-osx-overlay/tree/...
Gentooは、すでにニッチなLinuxコミュニティの中でも常にニッチだったが、それでも楽しく回り続けているように見える
何か問題があるのか？
同じソフトウェアを何度も不必要にコンパイルし続けたせいで、どれだけの電気代と温室効果ガスが発生したのかと思うとぞっとする
GentooがRed HatやUbuntuほど広く使われていたわけでもない
それに、コンピューターがどうせ起動していたなら、CPUの電力使用量は回転式HDDやモニターなどに比べれば丸め誤差レベル
キロワット級のゲーミングPCで1日12時間ゲームをする人もいれば、サーキットで車を走らせたり、燃費の悪いボートに乗り回したりする人もいる
Gentooを素晴らしいものにしているのは、自分のシステムに欲しい小さな調整を簡単に追加して保守できるよう、最初から設計されている点
自分が使った他のすべてのディストリビューション、主要ディストリビューション全部といくつかの小規模ディストリビューションは、デフォルト状態ではよりうまく動く傾向があるが、決められた道を外れると途端に大きな苦痛が伴う
きちんと調整したGentooシステムは、ただうまく動く™
ここで「うまく動く」が個人的に何を意味していても関係ない
Archが上流を上書きすると決めたときに起きるpython 2to3の名前衝突かもしれないし、SystemDがカーネルモードで不要なことをやりすぎるせいで生じるシステム中核部のレイテンシ問題かもしれない
いくつもの欠点にもかかわらず、自分は非常に満足しているGentooユーザーだ
上流のバイナリパッケージは、その自由のもう一つの拡張にすぎない
すでにいくつかの主要プロジェクトにはバイナリ版があったし、自分でビルドサーバーを作ることもできたが、より多くのバイナリを簡単に使えるようになれば、あらゆる小さなものをビルドする莫大な時間的負担なしに、はるかに多くの人がその利点を享受できる
特定のパッケージについて、パッチやuseフラグなど、より多くの柔軟性が必要なら、それは今でも可能で保守もしやすい
これは大きな勝利だ
しばらくの間、Gentooが本当に滑らかにうまく動いていたちょうどよい時期があった
useflagが多すぎも少なすぎもせず、寒い冬の夜に寮の部屋が寒すぎるとき、Open Officeを再コンパイルしていた頃だ
愛情を込めて言っている