今回は新しいソフトウェアがパッケージングされてリポジトリに入るまでを，libhinawaのパッケージングを事例に追いかけます。

パッケージとは

はじめに，パッケージとは何なのか振り返ります。

Ubuntuでは，様々なソフトウェアがパッケージという単位で管理されています。ソフトウェアを選択的に導入し，目的に沿ったシステムの構築を可能としています。ライブラリなどを利用する場合はソフトウェア間の関係性が発生しますが，パッケージ内に依存関係という情報を持ち，少ない手順で関連するソフトウェアをインストール可能としています。

Ubuntuのパッケージは，2つの観点から4つのコンポーネントに分類されます。2つの観点とは「対象のソフトウェアが自由ソフトウェアの哲学に適合しているかどうか」と「そのソフトウェアに対してサポートを提供できるかどうか」です。この場合のサポートとは，Ubuntuチームによるフルタイムの脆弱性対応が特定期間適用されるかどうか，ということです。4つのコンポーネントは以下です。

• Main：Ubuntuチームによってサポートされる自由／オープンソースソフトウェア。
• Restricted：Ubuntuチームによってサポートされるが，自由／オープンソースソフトウェアではないもの。特定デバイス用のプロプライエタリなソフトウェアが一例。
• Universe：Ubuntuチームの代わりにコミュニティによってサポートされるソフトウェア。自由／オープンソースソフトウェアライセンスに合致するもの。
• Multiverse：Ubuntuチームの代わりにコミュニティによってサポートされるソフトウェア。ライセンス上あるいは法的な問題といった課題を持つ。

Ubuntuプロジェクトでは，これら4つのコンポーネントのパッケージを保管するサーバーを運用しており，リポジトリと呼ばれています。Ubuntu Japanese Teamメンバーはリポジトリのミラーを日本国内に設置し，運用しています。また，他の団体によって運営されている国内ミラーもあります。

リポジトリ内のパッケージはUbuntuチームなど，コミュニティの中でも十分な権限を与えられている人が更新します。Ubuntuのベースシステムがインストールされたマシンは，定期的にリポジトリからパッケージ情報を取得し，アップデートできるものがあったらユーザに通知します。ユーザーは通知を受け，パッケージをアップグレードするかどうかを決めます。あるいはシステムの設定を変更することで，一部の更新が自動で適用されるようにできます。またユーザーは，リポジトリ内にあるパッケージを検索し，好みのものがあったらインストールできます。

2016年現在，Ubuntuではパッケージのフォーマットとしてdeb形式を採用しています（注1⁠）⁠。deb形式はDebianプロジェクトが設計した形式で（次項を参照⁠）⁠，内部にはビルド済みバイナリと配置情報，依存関係情報，インストール時に実行する処理などの情報を含んでいます。

リポジトリ内のパッケージに対して，むやみやたらに変更を加えることは好ましくありません。例えば更新したパッケージに機能後退がある場合，あるいは作成時の手違いによってパッケージとしての機能障害を持つものがある場合，そのパッケージ利用者全員に不便がもたらされます。これを防ぐために，パッケージをリポジトリに入れる，あるいはリポジトリ内のパッケージを更新する際の手続きには，事前の試験や開発者による複数回のレビューが含まれています。

注1

ただし，Snappy Ubuntu Coreのために専用のパッケージフォーマットであるsnappy packageが用意されています。

パッケージの由来

Ubuntuのリポジトリで提供されるパッケージの由来は2つあります。Ubuntuの手続きに従って持ち込まれたものと，Debianプロジェクトによってパッケージングされたソフトウェアです。

Debianプロジェクト由来のパッケージ

Debianプロジェクトは1993年にIan Ashley Murdockが始めたプロジェクトで，自由ソフトウェアを中心に構成されるディストリビューションの開発を重視したものです。そのポリシーはDebian Free Software Guideline（DFSG）として明文化されており，このポリシーに賛同する多数の開発者およびユーザーがDebianプロジェクトを支え，今日に至ります（注2⁠）⁠。

Ubuntuプロジェクトの創始者であるMark Shuttleworthは一時期Debianプロジェクトの開発者だったこともあり，UbuntuプロジェクトのベースシステムとしてDebianプロジェクトの成果を利用しました。以降，Ubuntuプロジェクトの開発者とDebianプロジェクトの開発者の交流が発生し，両プロジェクトはお互いの成果を持ち寄ることで進展していきました。事実，Ubuntuプロジェクトの開発者はDebianプロジェクトの開発者も兼任している場合が多く，単純なフリーライドの図式は全く当てはまりません。ただし，開発者の人数はDebianプロジェクトの方が多い点に留意してください。

Ubuntuのパッケージのうち，universe/multiverseコンポーネントに分類されるものはDebianプロジェクトに由来します。Debianのリポジトリ内のパッケージが更新されると，Ubuntuプロジェクトのbotがそれを捕捉し，パッケージソースのsyncを行って再ビルドしてリポジトリに配置します。

mainコンポーネントに分類されるパッケージもまた，Debianプロジェクトに由来するものがあります。サポート対象となるパッケージであるためインポートの過程がuniverse/multiverseと異なります。すなわち，Ubuntuチームが選択したパッケージのみインポートされます。

注2

Ianは2015年末にこの世を去りましたが，それにも関わらずDebianプロジェクトが続いているのは，この時代において十分に意義のある思想と，それに賛同する開発者およびユーザーの存在があるのだと思います。

Ubuntu独自のパッケージ

main/restrictedコンポーネントに分類されるパッケージの中には，様々な事情によりUbuntu独自にパッケージングしたものもあります。この他，諸事情によりDebianのリポジトリに入れることができないパッケージに対し，Ubuntu独自にパッケージングしてuniverse/multiverseに収録することもあります。そういった事情を持たないオープンソースソフトウェアは通常，こちらの道を辿らずにDebianを経由します。

Ubuntuのリリーススケージュール

一旦リリースされたUbuntuのバージョンで利用できるパッケージは，基本的にはバグの修正やそれに類する事情がない限りは更新されません。つまり，あるソフトウェアにおいて新機能が追加されたバージョンがリリースされたとしても，原則として，それがパッケージとして提供されることはないということです。これは「開発が終わった」からであり，新機能を含んだパッケージを導入することによって生じる不都合（試験の広範なやり直しなど）を考慮してのことです（注3⁠）⁠。

それでは，あるバージョンのUbuntuの開発期間中，ソフトウェアの新機能を伴うリリースのパッケージが受け入れられる期限はいつでしょうか。これがFeature Freezeと呼ばれるタイミングです。Feature Freezeを過ぎた場合，単なるソフトウェアのバグ修正やセキュリティに関係する修正を伴うパッケージ更新は受け付けますが，それ以外の理由によるパッケージ更新は次のUbuntuのバージョンに持ち越されます。このポリシーはパッケージの更新だけではなく，新規パッケージ受け付けにも適用されます。

Ubuntuのあるバージョンにおいて，Feature Freezeのタイミングは開発スケジュールによって決められています。例えば先月リリースされたUbuntu 16.04では，今年2月18日がFeature Freezeでした。パッケージの由来に関係なく，新しいパッケージをあるバージョンのUbuntuに持ち込むには，必要な手続きをこのタイミングまでに終えなければなりません。なお，この期限を超えて更新パッケージや新規パッケージを持ち込みたい場合は，Feature Freeze Exceptionという別の手続きを行う必要があります。

注3

この方針に対して，開発終了後の変更を許し，リリースの便益を確保する手続きとして，Stable Release UpdateやBackportが存在しています。16.04であれば，それぞれxenial-updatesリポジトリやxenial-backportリポジトリからその成果を利用可能です。