FedoraとRed Hat Enterprise Linux
パート3（4回シリーズ）：Fedora Coreの開発

執筆者: Tim Burke

原文(英語/2006年6月)

今回も、FedoraプロジェクトとRed Hat Enterprise Linuxを比較し、これら2つのディストリビューションを使用してお客様とコミュニティの参加者のニーズを満たす方法を説明する短期シリーズをお届けします。

これまでに、FedoraプロジェクトとRed Hat Enterprise Linuxの目標と目的を検討してきました。また、参加者についても検討し、各ディストリビューションで行われた開発のタイプを明らかにしました。

この記事では、Fedora Coreの共同開発に焦点を合わせます。

Fedoraの分類

Red Hat Enterprise Linuxは、Red Hatが提供するオペレーティングシステムディストリビューションです。Fedoraプロジェクトは、さまざまなオープンソースプロジェクトを推進することを目的とした幅広い統括団体です。これらのオープンソースプロジェクトは、新しいソフトウェアの開発からドキュメント作成、翻訳、およびボランティアによるテストの実施にまで及びます。

Fedoraプロジェクトは、メーリングリストとその他のフォーラムによってオンラインコミュニティの構築を支援しています。一連のFedoraプロジェクトは、Red Hat Enterprise Linuxに最終的に含まれるパッケージ一式よりもはるかに幅広いものです。

できるかぎり多くの参加を促すため、Fedoraでは、「Fedora Extras」のコンセプトを導入しました。「Extras」とは、関心のあるボランティアが各自のオープンソースソフトウェアを追加できる集合ポイントです。

Extrasに提出されたコンテンツが基本的な要件を満たし、初期品質審査を受けることを保証する基準が設けられています。Extrasは広く開かれているため、さまざまなコンテンツが受け入れられます。たとえば、Extrasには、同様の機能を実行する別パッケージが数多く存在する場合もあります。これによって、「最良のパッケージが勝ち残る」環境が醸成されます。

Red Hat Enterprise Linuxでは、同じ作業を達成するプログラムが複数提供されることはありません。企業ソフトウェアにおけるこのアプローチには、多くの理由があります。システム管理者が新規導入のたびに複数のアプリケーションをテストすることを期待するのは、現実的ではありません。また、長期サポートに伴う事情とあわせて、CDイメージには実際上、スペースの制約もあります。Fedora Extrasは、CDを作成しないことによってCDイメージのスペース上の制約を回避しています。それはすべて電子的に配布されます。

CDインストールメディアで収集および配布されるFedoraプロジェクトのパッケージは、「Fedora Core」と呼ばれています。

Fedoraに含めることができるソフトウェアのタイプ

Extrasでは、Linux上で動作するかぎり、ほとんどあらゆるものが考えられます。「スポンサー」が要求されます。Fedoraの維持管理者の誰かがソフトウェアを検討し、Fedoraコミュニティの少なくとも一部の関心に合致することを確認します。RPMのパッケージング、依存性の解決、およびその他の基本的な要件に関する追加的な説明が、fedoraproject.orgに掲載されています。

また、明示的に禁止されている事項もいくつかあります。

禁止リストには、次のような規則が含まれます。

• プロプライエタリである場合は、Fedoraに含めることはできません。
• 法的問題を引き起こしかねない場合は、Fedoraに含めることはできません。
• 米国の連邦法に違反している場合は、Fedoraに含めることはできません。

Fedoraの開発モデル

Fedora Coreディストリビューションは、パッケージのそれぞれのアップストリームコミュニティから、1,500個の個別パッケージ（アプリケーション、ライブラリ、マニュアル、カーネル、管理ユーティリティなど）を集約することによって開発されています。その例は次のとおりです。

• Apache Webサーバには、専門の開発コミュニティがあります。Red Hatの技術者は、Apacheコミュニティ内の開発を監視し、またそれに参加しています。Red Hatの技術者は、Apacheについて妥当な安定性を備えた最新バージョンを特定し、それをFedoraに統合します。
• Sambaプロジェクトに関与しているRed Hatの技術者は、適正なバージョンを選択し、Fedoraに含めます。1つのFedora Coreリリースについて、1つのパッケージが何度もアップデートされる場合があります。
• Red Hatの技術者は、Gnomeユーザインタフェースのウィジェットの開発に積極的に参加しており、Fedoraを通じてそれらの機能を公表することに関心を持っています。これによって、開発者は価値あるフィードバックを得られ、改良や拡張のための提案が集まります。

Fedoraパッケージの大部分がそれぞれのアップストリームのコードベースから継承されているとすれば、Red HatはFedoraでどのような開発を行うのでしょうか。

• 相互作用の問題 - 多くの作業が相互作用と依存性の問題を解決しています。基盤コンポーネントをアップデートすると、波及効果がもたらされることがよくあります。たとえば、コンパイラの新しいバージョンで、コンパイル時間エラーチェックが厳格化される場合があります。この場合は通常、影響を受けるパッケージで解決する必要のある一連の問題が発生します。
• プロジェクト管理 - Red Hatは、リリーススケジュールの確立を支援し、パッケージの依存性問題の追跡が最も容易になるメジャーバージョンを調整しています。ビルドインフラストラクチャの構築、ISO CDイメージの作成、電子配布メカニズムの開発といったリリースエンジニアリング作業も、Red Hatで行われています。通常、新しいFedora Coreのリリースは6ヶ月ごとに行われています。Red Hat Enterprise Linuxのメジャーリリース間の平均間隔は、18ヶ月です。
• バグ修正 - Red Hatの開発者は、多数の統合問題を解決し、それぞれのアップストリームコミュニティと連携して修正をフィードバックしています。
• インストーラとシステム管理ユーティリティ - ハードウェアを自動検出し、正しいドライバをインストールし、ユーザが必要なパッケージを選択でき、またシステムをサイト特有のニーズに適応させるツールも、Red Hatで開発されています。
• 新しい機能の開発 - コミュニティの開発作業の多くはFedoraソースツリーの外部で行われていますが、多数のプロジェクトがRed Hatの開発者によりFedora傘下のプライマリソースコードリポジトリを使用して主導されています。たとえば、クラスターファイルシステムであるRed Hat Global File System（GFS）や、Directory Serverなどです。

Fedoraへの参加方法

Fedoraのコミュニケーション拠点はhttp://fedoraproject.org/です。このサイトには、さまざまなFedoraプロジェクトの説明があり、参加方法に関するポインタやアドバイスをダウンロードできます。参加は、次のような多くの異なる役割で歓迎されます。

• アンバサダは、Fedora、Linux、およびオープンソースの普及を促進し、新しいボランティアを勧誘します。
• ドキュメンテーションチームは、エンドユーザや開発者に役立つコンテンツを作成します。
• テストおよびバグ格付けグループは、ユーザと開発者間の仲介役となります。
• 開発者は機能拡張やバグ修正を追加し、新しいソフトウェアへ完全統合します。
• トランスレータは、Fedoraが全世界の人々に役立つようにするため、テキストの翻訳や入力方式に関する作業に取り組みます。

この記事の焦点は開発にあるため、開発者がFedoraへの関与を深める方法について、さらに詳しく検討しましょう。fedoraproject.orgのページには、バグ修正への参加方法に関して詳細な説明があります。かなり大きな新しい機能をFedoraに組み込みたい場合は、次の項で、その一般的な達成方法を詳しく説明しています。

Fedoraへの新機能の統合を試みるための前提知識

1.当該機能について、プライマリアップストリーム開発サイトを特定します。たとえば、Apache Webサーバのプライマリリポジトリは、Fedoraの外部にあります（Fedoraが主にこの外部パッケージを統合しているため）。パッケージには、Directory Serverのように、Fedora内で直接開発が進められているものもあります。
2.当該機能がFedora Coreへの統合に適しているか、またはFedora Extrasに適しているかを特定します。新しいFedoraコンテンツの大部分は、Extrasに配置されます。これによって、開発がCore全体の配布スケジュールに左右されないため、開発者は最大限の柔軟性を得られます。

Fedora Coreへの統合に適したプロジェクトは、多くの場合、インフラストラクチャコンポーネントになります。これは、一般的に使用される多数のシステムユーティリティやサービスに対して依存性があります。Fedora Coreプロジェクトの1つの目標は、Coreに含まれるパッケージの数を絶えず削減し、できるかぎり多くのパッケージをExtrasへ移転することです。これは、実際的な理由で行われています。それによって、Coreを適度な数のCDに収めることができ、ダウンロードやアップデートで大量のネットワーク帯域幅が消費されることを防止できます。

プライマリアップストリーム開発サイトがFedoraの外部にある機能について開発作業を実行するには、そのサイトの開発者とやり取りします。このようにして、各機能の主な開発作業が、統合されたコミュニティ内で実施されます。その後、Fedoraはこの新しいソフトウェアのスナップショットを定期的に継承します。

Fedoraの新しい機能の開発は、その大部分が直接Fedora内では行われません。そこで、Fedoraプロジェクトでは統合作業に重点が置かれます。Fedoraは、精力的に活動する既成の開発チームが参加している各プロジェクトを分岐させておくつもりはありません。

Fedoraの新しい機能拡張について、Red Hatに問い合わせがくることがよくあります。そのような場合は、たいていそれぞれのアップストリーム開発クルーを紹介しています。新しい機能がアップストリームパッケージ（Apacheなど）に統合されると、次回、そのパッケージがリベースされたときにFedoraへ取り入れられます。「リベース（rebase）」とは、特定のパッケージについてソースコードのバージョンを置き換えることです。つまり、旧いバージョンを新しいバージョンと交換するということです。

Fedoraの開発の特徴は、リベースが頻繁に行われることです。リベースの頻度は、パッケージによって大きく異なります。たとえば、開発期間の大部分で、カーネルは週に数回リベースされることがあります。他のパッケージでは、半年ごとに1回という場合もあります。これは、それぞれのアップストリーム開発プールでの変更のペースに大きく依存しています。

自分の新しい機能はFedora Extrasへ含めるのが最も適当であると判断した場合は、参加方法を記述したガイドラインがあります。

Fedora Coreのパッケージを変更したい場合は、まず変更したいパッケージのアップストリームコミュニティから始めます。新しいパッケージをFedora Coreへ組み込みたい場合は、fedora-devel-list@redhat.comメーリングリストで議論を開始するのが最善です。このリストには加入できます。

Fedora開発に最も適した機能のタイプ

Fedoraプロジェクトは、Linuxの統合の中心であり、パッケージ間の相互作用の問題を解決し、さまざまな作業負荷のもとでユーザテストを幅広く実施するための最適な場所です。次に、Fedora開発に適したプロジェクトのタイプを示す過去の事例をいくつか挙げます。

• SELinuxは、きめ細かいセキュリティ機能の実装です。この機能では、多数のシステムサービスに変更を加える必要がありました。実装の目標は、動作を損なうことなく、エンドユーザの期待が大きい強化されたセキュリティを選択できるようにすることでした。すばやく修正を行い、エンドユーザテストを幅広く実施できるため、Fedoraは理想的な開発研究所となります。この作業の大部分は、政府出資の技術陣と連携してRed Hatの技術者により実行されました。
• Modular Xは、ビルドシステムから、ハードウェアとカーネル間の相互作用、ディストリビューションのパッケージング、インストーラ、パッケージ依存性まで、システムに多大な影響を与えます。これは、Fedoraでの幅広いコミュニティ開発とテストの恩恵を受けた主要な統合作業でした。
• Kexec/Kdumpは、新しいクラッシュダンプ機能です。このプロジェクトには、カーネルインフラストラクチャやハードウェアドライバコンポーネントなど、いくつかの部分があります。一連の関連コマンドとユーティリティがシステムクラッシュダンプの設定と生成に使用されます。また、ダンプイメージの検査に使用される一連のクラッシュ分析ツールもあります。さまざまなコンポーネントと多くのユーザに対するそれらの機能を収集できるため、Fedoraは理想的なホスティング環境となります。この作業の多くは、Red Hatのコア開発チームと緊密に連携しているビジネスパートナー所属の技術者によって推進されています。

Fedoraに適しているのは、次のような特徴を持つ場合です。

• 多くの異なるコンポーネントで構成され、したがって統合を適用することに利点がある。
• すばやいフィードバックサイクルを受け入れられる。
• さまざまなハードウェアと作業負荷上でテストを実施することに利点がある。
• 幅広いユーザに受け入れられるはずである。

たとえば、既存のFedoraユーザのごく一部しか興味を持たないような難解な機能は、多くの参加が得られるとはあまり考えられません。そうした機能をFedora Coreへ統合しようとする場合は特にそうです。目標は、あくまでCoreの基盤セットを縮小していくことにあります。

難解なパッケージは、Fedora Extrasに含める方が適しています。

Fedora Coreのリリース手順

Fedora Core（FC4、FC5）の新しい完全リリースは、およそ6カ月ごとに登場します。主な中間段階は、次のように構成されています。

• rawhide - 開発サイクル全体を通じて、ソフトウェアパッケージの最も重要な最新バージョンは「rawhide」と呼ばれます。rawhideは通常、夜間にビルドされ、最前線の開発に参加する場所として最適です。rawhideによって、開発者とテスト技術者は、最新リリースをリポジトリから容易に引き出し、インストールしてテストすることができます。統合の問題は、多くの場合、rawhideで最初に発見されます。rawhideの使用は、気弱な人には向きません。それは安定性に欠ける場合がよくあります。そのため、より安定したバージョンが提供される暫定リリース段階があります。
• Test1とTest2 - これらのテストリリースは、不安定化をもたらす可能性がある大きな機能を統合用に作成する場合の主要な開発基準レベルとなります。これは、リリースサイクルの初期に実施されます。Test1とTest2の継続期間は、約6週間です。
• Test3 - これは、最新の開発基準レベルです。ここでは、重要性の低い機能やバグ修正が組み込まれます。影響の大きい機能は組み込まないことが強く推奨されます。Test3の主な目的は安定化です。Test3の継続期間は、約6週間です。
• Final - 「Final」は、最後の基準レベルに与えられた用語です。対処されるのは、先行するTestの基準レベルで発生した問題のバグ修正だけです。新しい機能は、この期間中には組み込まれません。この最終基準レベルで重大な問題が発生した場合は、リビルドされます。継続期間は通常、4～6週間です。最終ビルドの完了が宣言されたあと、1週間の期間がとられます。この時間は、最終ディストリビューションのためにISOおよびRPMパッケージを実施し、ミラーサイトへの転送を開始するために使用されます。

Fedora Coreディストリビューションがリリースされたら、パッケージの新しいバージョンはyumリポジトリから入手できます。このコンテキストでは、新しいパッケージは「アップデート」と呼ばれます。

次号：このシリーズの最終記事では、Red Hat Enterprise LinuxがFedoraプロジェクトと共通の目標を持っていることを説明します。また、お客様の企業のニーズに合わせてRed Hat Enterprise Linuxの開発モデルを調整する方法についても説明します。