今回は新しいソフトウェアがパッケージングされてリポジトリに入るまでを、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プロジェクトが設計した形式で（次項を参照⁠）⁠、内部にはビルド済みバイナリと配置情報、依存関係情報、インストール時に実行する処理などの情報を含んでいます。

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

パッケージの由来

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チームが選択したパッケージのみインポートされます。

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という別の手続きを行う必要があります。

新しいソフトウェアのパッケージがリポジトリに入るまで

ここからは、私が実際に体験したパッケージングプロセスを紹介します。

私はlibhinawaというライブラリを開発しています。用途に関しては、この記事の主題から外れるので省略します。GLibのアプリケーションであり、またGObject Introspectionの作法に対応しています。ビルドシステムとしてGNUのAutotools一式を使います。キャラクタデバイスとの入出力を行うGMainContextを回すため、スレッドを一つ確保します。キャラクタデバイス越しにLinux固有の操作を行うので、LinuxのUAPIヘッダの一部を利用したアプリケーションでもあります。libhinawaはここに述べたソフトウェアと依存関係を持ちます。

開発の背景について大雑把に説明します。私が行っている作業はユーザーからの適切な情報提供があるととても楽に進みます。しかし十分に役立つツールがこの世界に存在していませんでした。この現状を何とかするべくlibhinawaを開発しました。私の助言を必要とするユーザーに毎度ソースからコンパイルするよう案内するのは手間で、そして実際に手間だったので、いずれかのディストリビューション開発プロジェクトにパッケージングしてもらいたいと考えるようになりました。私はUbuntuを使いソフトウェア開発をしているので、Ubuntuのリポジトリに入れたいと思うようになったのは当然の流れでした。

Debパッケージング作業とメンテナ探し

コミットログを確認すると、2014年9月4日の少し前に開発を開始したようです。2015年2月に開発を一旦停止し、debパッケージングに着手しています。この作業は岡田義弘さんに手伝ってもらい、進めました。この時点では、debパッケージを生成できる程度の完成度にとどめていて、Debian側に働きかけることは考えていませんでした。私も岡田さんもDebianのパッケージングの作法にはそれほど明るくなく、十分な品質のパッケージを生成できなかったからです。また私はLinuxカーネルのメインライン向け作業に時間を割く必要がありました[4]⁠。パッケージング作業に見切りを付けた後はカーネルランドの作業の合間を見つけてlibhinawa本体の開発を進めましたが、それ以上のことをするだけの時間の余裕がありませんでした。

転機は2016年1月にありました。Debianプロジェクトのgroongaパッケージのメンテナであるクリアコード社の林健太郎さんと会う機会があり、それとなくlibhinawaのdebパッケージングの話を持ちだしたところ、興味を持っていただけたのです。libhinawaのソースコードを点検してもらったところ、少々手直しすればDebian側に持っていけそうということでした。Linuxのメインライン向け作業が一息ついたタイミングでもあったため、libhinawaのパッケージング作業に時間を割くことにしました。

林さんとはGitHubのissue機能とpull request機能を使ってコミュニケートし、準備を行いました。主な作業はdebパッケージングに関係する設定ファイルの改良でしたが、この過程でAutotools設定ファイルのバグが見つかり、修正しました。

DebianへのITPとsponsor

debパッケージとしての形式が整ったため、DebianへITPしました。ITPとはIntent To Packageのことで、当該のソフトウェアについて誰かがパッケージング作業をしていることを周知する手続きです。DebianのバグトラッキングシステムにlibhinawaをITPする旨を登録しました。

パッケージは登録するだけではDebianのリポジトリには入りません。Debian開発者と呼ばれる、プロジェクトで十分に信任を認められた開発者による確認を経る必要があります。このような開発者はパッケージに対するsponsorと呼ばれ、sponsorを探していることを登録する手続きをRFS（Request For Sponsor）と呼びます。Debianプロジェクト側の作業をしている林さんもまして私もDebian開発者ではないため[5]⁠、sponsorを見つける必要があります。ITPに合わせ、libhinawaのRFSを行いました。

登録して3日目にHIGUCHI daisukeさん（dai）がsponsorとして名乗りを上げてくれました。何点かパッケージング上の修正箇所を指摘され、林さんに修正していただきました。daiさんによって、libhinawaがNew queue入りしました。

New queueとは、パッケージをDebianのリポジトリに入れる最後の手続きです。FTP masterと呼ばれる、パッケージをサーバーにアップロードする権利を持つDebian開発者による最終確認の手続きであり、queueには確認待ちのパッケージが詰まれています。ここにどのくらい時間がかかるのかはFTP master達の都合次第です。パッケージメンテナよりも少ない人的資源に依存するプロセスですので、かつてはそれなりの期間を待たされることもあったようですが、近年ではプロセスが改良され、短期間に処理されるようになったと聞いています。

我々にとって幸運だったのは、new queue入りして1日で処理されたことです。こうしてITP後5日目に、無事Debianリポジトリ入りしました。

Ubuntuプロジェクトへのsync

ここまでの進捗を見るに、Ubuntu 16.04のDebian Import Freezeである2016年2月18日に間に合わせることも十分視野に入ってきました。当初は、Debian Import Freezeに間に合わせるには動き出しが遅かっため、こんなに順調にDebian側の手続きが終わる場合を考えておらず、Ubuntu側でのアクションを調べきれていませんでした。

そこで、libhinawaのDebian unstable入りを確認した後、Ubuntu Japanese Teamのメーリングリストでautosyncに関する質問をしました。本連載でもお馴染みのあわしろいくやさんが返事をくださいました。自動でsyncされるということで、launchpad.netを確認するとDebian unstable入りから12時間程度でUbuntu側のbotに捕捉され、先述の処理を経てuniverseリポジトリに入りました。

パッケージの更新

Debianのlibhinawaパッケージですが先日、Debianプロジェクトに報告されたバグおよびcryptographic signature verificationに対応するべく、更新パッケージを提供しました。

cryptographic signature verificationはパッケージのソースとなる圧縮アーカイブをGnuPGを使ってファイル署名しておくことで、改ざんされているかどうかをdebパッケージング処理中に検出する仕組みのことです。libhinawaの圧縮アーカイブはGitHub上にあって改ざんの危険性がそれなりにあります。この改ざんへの対策として、cryptographic signature verificationは有効であり、林さんの提案を受けて対応することにしました。パッケージへの署名には私のGPG鍵を用いました。というのも以前から私は他の開発者とキーサインを交わし、web of trustを構築していたからです。

この更新もまたUbuntu側のbotに捕捉され、すでに16.10向けのパッケージが提供されていますが、16.04向けパッケージは先述の理由のために更新されていません。今回の更新はソースの変更を伴わないパッケージング上のバグ修正なので、適当な手続きを行えば更新パッケージが提供できるはずです。16.04はLTSですし、時間を見つけて手続きを行おうと考えています。