Product SiteDocumentation Site

1.6. リリースライフサイクル

Debian プロジェクトは同時にそれぞれのプログラムの 3 か 4 つの異なるバージョンを持っており、実験版不安定版テスト版安定版、のように名づけられています。各バージョンは開発の異なる段階に相当します。違いを十分に理解するために、どのような順序でプログラムが最初のパッケージ化から Debian の安定版に取り込まれるかを見てみましょう。

1.6.1. 実験版 状態

まず最初に特殊な例である実験版ディストリビューションについて見てみましょう: これは現在開発中のソフトウェアに相当する Debian パッケージのグループで、名前の示す通り開発を終えている必要はありません。すべてのパッケージがこのステップを踏む必要はありません; 一部の開発者はより経験豊かな (優れた) ユーザからのフィードバックを得るためにパッケージをここに追加します。
別の面では、このディストリビューションは、基盤パッケージに対する重要な変更を一時的に取り込む際に、よく使われます。深刻なバグを含む基盤パッケージを不安定版に取り込むと深刻な影響があります。そんなわけで、このディストリビューションは完全に隔離されたディストリビューションです、ここに含まれるパッケージは決して他のバージョンに移行することはありません (メンテナまたは ftp 管理者からの介入という例外を除きます)。また、このディストリビューションは自己完結していません: 実験版の中には既存のパッケージの一部だけが含まれており、基盤システムは含まれません。それゆえこのディストリビューションは通常、不安定版などの自己完結している他のディストリビューションと組み合わせて利用されます。

1.6.2. 不安定版状態

典型的なパッケージの場合に戻りましょう。メンテナが不安定版用にコンパイルされた最初のパッケージを作成し、ftp-master.debian.org サーバに置きます。その後、ftp 管理者がパッケージを検査検証します。そうすると、ソフトウェアは不安定版ディストリビューションで利用可能になります。このディストリビューションは深刻なバグを心配するよりも、パッケージを最新にすることに関心があるユーザの選択する、「最先端の」ディストリビューションです。そのようなユーザがプログラムを見つけて、テストします。
ユーザはバグに遭遇すると、バグをパッケージメンテナに報告します。メンテナは定期的に修正済みバージョンを用意し、サーバにアップロードします。
新たに更新されたパッケージはすべて、6 時間以内に世界中のすべての Debian ミラーで更新されます。そしてユーザが修正をテストし、変更したことで生じる別の問題を探します。いくつかの更新は素早くなされるかもしれません。これらの間、自動ビルドロボットが活動を始めます。多くの場合、メンテナは古い PC を一台だけ持っており、amd64 (または i386) アーキテクチャでパッケージをコンパイルしています。自動ビルドロボットはコンパイル作業を引き受け、すべての他のアーキテクチャ向けのバージョンを自動的にコンパイルします。いくつかのコンパイルは失敗するかもしれません; メンテナは問題の内容を含んだバグ報告を受け取り、このバグは次のバージョンで修正されます。問題となっているアーキテクチャの専門家がバグを発見した場合、そのバグ報告にはすぐに使えるパッチが添えられているかもしれません。
自動ビルドロボットによるパッケージのコンパイル

図1.2 自動ビルドロボットによるパッケージのコンパイル

1.6.3. テスト版 への移行

しばらくするとパッケージは成熟するでしょう; すべてのアーキテクチャ上でコンパイルされ、最近行った変更が無くなるでしょう。こうなると、将来テスト版ディストリビューションに組み込まれる対象になります - 不安定版パッケージのグループが定量化可能な基準に従って選ばれます。毎日あるプログラムが、一定の品質水準を保証する要素を基に、テスト版に組み込むためのパッケージを自動的に選びます:
  1. 深刻なバグが無いこと、もしくは現時点でテスト版に組み込まれているバージョンよりも少ないこと;
  2. 不安定版に組み込まれてから少なくとも 10 日経っていること、これは深刻な問題が発見されて報告されるのに十分な時間です;
  3. 公式にサポートされているすべてのアーキテクチャ上でコンパイルに成功していること;
  4. テスト版で依存関係を満たす事ができること、そうでなければ少なくとも問題となっているパッケージの準備ができたら一緒に移動する事が可能です。
このシステムは明らかに絶対確実なものではありません; 深刻なバグは通常テスト版に組み込まれたパッケージから見つかります。とはいっても、このシステムは有効で、テスト版不安定版に比べて問題がはるかに少なく、長い間安定性と新規性の良い妥協案でした。

1.6.4. テスト版から安定版への昇格

我々のパッケージが今現在テスト版に組み込まれたと仮定しましょう。改善の余地がある限り、メンテナはパッケージを改善し続け、不安定版からの一連の手順を最初からやり直さなければいけません (その後テスト版へは素早く取り込まれる事が多いです: 大きく修正されておらず、すべての依存関係が既に利用可能な場合に限ります)。パッケージが完成の域に達すると、メンテナの仕事は完了です。次のステップは安定版ディストリビューションへの取り込みです、実際のところこれはリリースマネージャが選んだ時点におけるテスト版の単純なコピーです。理想的にはこの決断はインストーラの準備が整った時点、そしてすべてのテスト版に含まれるプログラムで既知の致命的バグが解決された時点に行われます。
このような理想的瞬間は絶対に来ないので、実際問題として Debian は妥協しています: メンテナが時間どおりにバグを修正できなかったパッケージを削除したり、多数のプログラムが数個のバグを抱えた状態でディストリビューションをリリースすることに同意したり、します。リリースマネージャは事前にフリーズ期間をアナウンスし、テスト版への更新はこの期間中に承認されなければいけません。フリーズ期間を設ける目的は、バージョンが新しくなる更新 (と新たなバグの混入) を禁止し、現在のバージョンに対するバグ修正の更新だけを受け入れる事です。
様々な Debian バージョンの間をパッケージが移行される様子

図1.3 様々な Debian バージョンの間をパッケージが移行される様子

新しい安定版のリリース後、安定版リリースマネージャがすべての追加的開発を管理します (「リビジョン」と呼ばれます、例: バージョン 5 のリビジョンは 5.0.1、5.0.2、5.0.3 など)。これらの更新にはすべてのセキュリティパッチが体系的に組み込まれています。更新には最も重要な修正も含まれています (パッケージのメンテナが、更新を含めてもらうためには、修正を望む問題の重大性を証明しなければいけません)。
最後に、仮想パッケージが安定版ディストリビューションに取り込まれます。ここに到達するまでには大変な苦労があり、Debian 安定版のリリースが極めてゆっくりと進む理由がお分かりになったと思います。この遅さは品質評価に貢献します。しかも、大多数のユーザは同時に利用可能な 3 つのディストリビューションのうち 1 つを使えば満足です。システム管理者は、何よりもまず彼らのサーバの安定性を重要視しており、最新バージョンの GNOME は必要ありません; 彼らは Debian 安定版を選んで、それに満足するでしょう。エンドユーザは、強固な安定性よりも最新バージョンの GNOME や KDE に興味があり、Debian テスト版を選ぶでしょう。このディストリビューションは深刻な問題が少なく、比較的新しいソフトウェアが使えるという意味で両者の良い妥協点です。最後に、開発者と経験豊富なユーザは道を切り開くかもしれません。彼らは Debian 不安定版になされたすべての最新の開発を真っ先にテストし、面倒事とプログラムの新しいバージョンにつきものであるバグに苦しむという危険を冒します。人それぞれ好みの Debian があるのです!
Debian のパッケージ化するプログラムが時間ごとに辿る経路

図1.4 Debian のパッケージ化するプログラムが時間ごとに辿る経路