Fedora 45 ソーセージ工場

Fedora 45 ソーセージ工場 この記事は、Fedora がソースコードとパッケージを、ダウンロードしてインストールする成果物にどのように変換するかを解説するウォークスルーです。Packager の git push から、ISO、クラウドイメージ、コンテナイメージ、OSTree デプロイメントといった完成されたリリースまでのパッケージの旅を追います。 このウォークスルーでは、Fedora の「ソーセージ」が Fedora 45 時点でどのように作成されるかを説明します。物事は常に変化するため、このドキュメントを Fedora リリースの各サイクルまたは数サイクルごとに更新し、歴史と最新情報を提供できれば幸いです。 実際、Fedora 45 はまだリリースされていないため、この記事は現在も更新中の状態にあり、リリースまで更新される可能性が高いです。この投稿の大部分を占める boot.iso の生成方法など、いくつかの変更提案が進行中です。 そのため、もし何か間違っている点があれば、私に知らせていただくのに良い時期でもあります。間違いを見つけた場合は、cmd r@supakeen.com までメールでご連絡ください。 開始点: dist-git すべては、Packager がパッケージにコミットをプッシュすることから始まります。 Fedora は、src.fedoraproject.org にある個々の Git リポジトリに、すべてのパッケージのソース定義を格納しています。各リポジトリには、RPM spec ファイル、ダウンストリームパッチ、および別のルックアサイドキャッシュに格納されているアップストリームの tarball を指す sources ファイルが含まれています。大きなバイナリファイルは Git から除外され、その他のファイルは Git 内に存在するため、完全なバージョン管理が行われます。 Packager は通常、fedpkg という CLI を介してこれらのリポジトリとやり取りします。fedpkg は、リポジトリのクローン、ソース tarball のアップロード、ビルドの送信、アップデートの作成といった一般的な操作をラップします。fedpkg build の重要な点は、それが実際に行うことです。それは、Git リポジトリの特定のコミットを指す URL を構築し、それをビルドシステムである Koji に渡します。ビルドは、そのコミットハッシュから完全に再現可能です。 ブランチはリリースに対応します: 開発用は rawhide、Fedora 44 用は f44 です。ホスティングは Pagure (src.fedoraproject.org) と Forgejo (forge.fedoraproject.org) に分かれており、前者の移行が進行中です。 Packager は fedpkg を使用せずに作業することもできますが、この投稿の目的のためには、読者にとって無関係な部分を抽象化してくれる fedpkg が使用されていると仮定する方が簡単です。 パッケージのビルド: Koji fedpkg build がその Git URL を送信すると、Koji が引き継ぎます。Koji は Fedora のビルドシステムです。Fedora 7 から存在しており、基本的にすべてのものをビルドします。 Koji はハブアンドスポークアーキテクチャに従っています。ハブは、PostgreSQL データベースの前面にあるパッシブな XML-RPC サーバーです。ビルダーデーモンはハブにポーリングして作業を取得し、各ビルドのために新しい Mock chroot 環境を作成し、ビルドを実行し、結果をアップロードします。すべてのビルドはクリーンルームから開始されます。ビルダーに先週何かをインストールしたという理由で、異なる結果を得ることは決してありません。 組織モデルはタグを中心に構築されています。タグとは、ビルドの命名されたコレクションです。ビルドターゲットは、受信したビルド要求を 2 つのタグにマッピングします。ビルドタグ（ビルド中のビルドルート、利用可能なパッケージを定義します）と、完了したビルドが配置されるデスティネーションタグです。タグは複数継承をサポートしているため、すべてを複製せずに Fedora 44 タグをベースタグの上に重ねることができます。 Koji は RPM をビルドするだけではありません。プラグインシステムとコンテンツジェネレーターを通じて、イメージビルドもオーケストレーションします。Kiwi イメージは kiwiBuild タスクタイプを介して、Image Builder アーティファクトは imageBuilderBuild を介して、OSTree コンポーズは runroot タスクを介して行われます。それらについては後述します。 アップデートのゲート処理: Bodhi Koji にある新しい RPM ビルドは、自動的にユーザーに届くわけではありません。ブランチリリース（Rawhide 以外）の場合、Fedora のアップデート管理システムである Bodhi を通過します。 Bodhi は、フィードバックとテストのサイクルを通じてアップデートのリリースをゲートします。Packager は 1 つ以上のビルドを含むアップデートを送信します。そのアップデートは、保留中、テスト中、安定版という一連の状態を通過します。ユーザーと自動テストがカルマ（+1 / -1）を提供します。アップデートが +3 カルマに達するか、テスト中に十分な日数を費やすと、自動的に安定版にプッシュされます。アップデートが +1 カルマに達した場合、メンテナーは手動で安定版にプッシュできます（クリティカルパスの場合は +2）。 舞台裏では、Bodhi は Koji タグを通じてこれらすべてを管理しています。アップデートがテスト中から安定版に移動すると、Bodhi はビルドを f44-updates-testing タグから f44-updates タグに移動します。その後、Pungi を呼び出してアップデートリポジトリをコンポーズします。これは、ユーザーが dnf upgrade を実行したときにプルする実際の yum/dnf リポジトリです。 システムの起動と機能に必要なクリティカルパスパッケージは、より厳しい要件があります。7 日ではなく 14 日間テスト中で、より多くのカルマが必要です。Bodhi はまた、Greenwave および ResultsDB と統合して CI テストゲート処理を行うため、自動テストの失敗はアップデートが安定版に到達するのをブロックする可能性があります。 Rawhide の場合、これらのプロセスは異なるように設定されています。非クリティカルパスパッケージは、ゲートポリシーがある場合（パッケージがクリティカルパスにあるか、パッケージ自体にポリシーがあるため）はすぐに安定版になりますが、それでも適用され、合格するまでアップデートは保留される可能性があります。 リリースのコンポーズ: Pungi 個々の RPM は、Bodhi のゲート処理があっても、単なるパッケージです。それらをダウンロードしてインストールできるもの、つまり ISO、クラウドイメージ、リポジトリに変換するのは Pungi の仕事です。 Pungi はコンポーズオーケストレーターです。それ自体は多くの重い作業を行いません。代わりに、それらがすべて同じ一貫したパッケージセットからビルドされることを保証しながら、それを行うツールを調整します。 Pungi という名前は、ヘビ使いの楽器であるプンギー（pungi）への言及です。それは Fedora のインストーラーである Anaconda を「魅了」します。この言葉遊びは 2006 年から続いています。 コンポーズは、pungi-koji が実行されるときに開始されます。これは、夜間の Rawhide コンポーズのために cron によってトリガーされるか、マイルストーンリリースを手動でトリガーされるかのいずれかです。設定ファイル（Fedora の場合、pungi-fedora リポジトリ内の fedora.conf）をロードし、一連のフェーズを実行します。 パッケージセットのフリーズ Pungi が最初に行う実際の作業は、Koji タグからパッケージセットのスナップショットを作成することです。これは Pkgset フェーズであり、非常に重要です。後続のすべてのフェーズはこのフリーズされたセットから作業します。コンポーズの実行中に誰かが Koji に新しいビルドを送信しても、コンポーズにこっそり入ることはありません。タグベースのスナップショットにより、コンポーズ全体が監査可能になります。どのコンポーズにどのバージョンのどのパッケージが含まれていたかを常に正確に特定できます。 どこに何を入れるかを決定する: comps とバリアント パッケージがフリーズされたら、Pungi はどのパッケージがどの製品に属するかを決定する必要があります。ここで 2 つの XML 入力が登場します。 comps (fedora-comps) は、gnome-desktop、server-product、core のような関連パッケージのコレクションであるパッケージグループを定義します。グループ内の各パッケージには、mandatory、default、optional、conditional のいずれかのタイプがあります。これは、dnf group install および Anaconda のソフトウェア選択画面を強化するのと同じグループ化システムです。 variants XML (pungi-fedora 内の variants-fedora.xml) は、コンポーズ内の製品を定義します: Everything、Server、Workstation、KDE、Silverblue など。各バリアントは、含まれる comps グループとサポートされるアーキテクチャをリストします。最新の Fedora のほとんどのバリアントは is_empty="true" であり、Everything バリアントのリポジトリからのパッケージのみを使用してイメージ（Kiwi、Image Builder、または OSTree を介して）を生成することを意味します。Everything と Server だけが実際にパッケージ収集パイプラインを実行します。 ブートイメージのビルド Buildinstall フェーズは lorax を実行して、Anaconda インストーラーをブートするイメージである boot.iso を作成します。Lorax は最小限のパッケージセットを一時的なルートにインストールし、Anaconda 環境を設定し、それを install.img に圧縮し、ブートローダーでラップして ISO にします。各バリアントアーキテクチャの組み合わせに対して 1 つの lorax タスクが実行され、通常は分離のために Koji の runroot 環境で実行されます。 結果として得られる boot.iso は、インストーラー ISO の基盤です。それ自体にはパッケージは含まれていません。それらは次のステップでレイヤー化され、dvd.iso が生成されます。 ISO の生成 Createiso フェーズは、Buildinstall からの boot.iso を取得し、その上にパッケージとリポジトリメタデータをオーバーレイして使用します。