Snapパッケージのサポート方針に関する議論
「Snapパッケージ（Snapソフトウェア）」のサポート方針に関する議論が行われています。
SnappyとAPT
「Ubuntu」ではデフォルトで、以下のパッケージ管理システムに対応しています。| パッケージ管理システム | パッケージフォーマット |
|---|---|
| APT | deb |
| Snappy | snap |
「Snappy」は「APT」より後から登場したパッケージ管理システムであり、ソフトウェアの隔離や高度なバージョン管理など「APT」にはない機能を備えています。
「Snappy」は「Canonical」が中心に開発していることもあり、「Canonical」が後ろ盾となっている「Ubuntu」でも積極的な展開が行われています。
ところで「Snaps」は「Snapパッケージ」を指す言葉ですが、文章によっては「Snapパッケージ」で提供されるソフトウェアや枠組み全体を指すこともあります。
前後の文章から意図を汲み取ると良いでしょう。
Snapパッケージとは
「Snapパッケージ」は、従来のパッケージフォーマットである「deb」や「rpm」等に代わる新しいパッケージフォーマットです。「Snapパッケージ」が利用できるOSは「Ubuntu」だけでなく、「Debian」「Fedora」「Arch Linux」「openSUSE」など、様々なOSで利用できます。
「Snapパッケージ」は隔離された環境にソフトウェアを配置するため、他のソフトウェアや既存のシステムに影響を与えることなくソフトウェアのインストールや利用が可能です。
またもしソフトウェアで不具合などの問題が発生すれば、以前のバージョンにロールバックする機能も備えています。
「Snapパッケージ」はLinuxのソフトウェアをパッケージ化するための次世代のパッケージフォーマットです。
snapとdebは共存可能
「Snapパッケージ」は隔離された環境にソフトウェアを配置するため、既存の「deb」で構築されたシステムに影響を与えることなく共存することができます。Ubuntuはdebパッケージを中心に構築されている
現在の「Ubuntu」は、「APT/debパッケージ」を利用して構築されています。つまりデフォルトでインストールされるソフトウェア群は、「debパッケージ」から提供されているソフトウェアです。
ただ「snap」もデフォルトでインストールされているため、ユーザーは必要なら「Snapパッケージ（Snapソフトウェア）」をインストールすることも可能です。
またデフォルトでインストールされている「ソフトウェア」は、snap及びdebから提供されるアプリのインストールに対応しています。
debパッケージのサポート方針
「Ubuntu」では「Canonical」のサポート対象になっている「debパッケージ」に対し、LTS版で5年間のサポート期間を、通常版で9ヶ月のサポート期間を提供しています。このような「debパッケージ」で提供されるソフトウェアは、サポート期間中であればセキュリティーアップデートが提供されます。
mainとrestricted
「main」と「restricted」に配置される「debパッケージ」は、「Canonical」のサポート対象になります。
アップデートに関しては、「backports」は「Canonical」のサポート対象外になります。
デフォルトでインストールされるパッケージ
「Ubuntu」のディスクイメージに含まれ、デフォルトでインストールされるパッケージは、「Canonical」のサポート対象になっているパッケージです。逆に言えば「Canonical」のサポート対象になっていないパッケージをデフォルトで提供することはできません。
Snapパッケージのサポート方針どうしよう？
しかし今現在「Snapパッケージ」に対し、「debパッケージ」のような明確なサポート方針は定義されていません。そのため「Snapパッケージ」をデフォルトで提供するためには、まずサポート方針を明確にし、それを基にした作業及びサポート方針をユーザーに提示する必要があります。
以下でサポート方針に関するアイデアが提案されています。
まだまだ具体的に煮詰め、開発者間で共通認識を形成しなければならない状況です。
目標
「Snaps」はソフトウェアの導入の障壁を軽減する新しいパッケージのビルド方法です。設計上パッケージのビルドツールである「snapcraft」は、パッケージ間（バージョン）の衝突を避けるためのポリシー（制約）がほとんどなく、「debパッケージ」のようなポリシーから解放されています。
さて多くのソフトウェアが「Snaps」として提供されるようになり、これらを「Ubuntu」のデフォルトのユーザー体験の一部として取り込み、「Snaps」の利点をユーザーに提供したいと開発チームは考えています。
しかしデフォルトのユーザー体験の一部として取り込み、Ubuntuコミュニティーが持つ責任を確保するには、「Snaps」上にポリシーを再導入することになります。
ここでは「debパッケージ」に適用されてる既存のポリシーを「Canonical Snap Store」に当てはめてみましょう。
チャンネルの活用
デフォルトでインストールするソフトウェアを「Ubuntu」に含めるということは、それらのソフトウェアのアップグレードを円滑に行えるようにし、「Ubuntu」の安定版リリース内において、継続的に安定したソフトウェアのアップデートを提供してく必要があるということです。この点において「debパッケージ」のようなサポートポリシーを提供する最善の方法は、「stable」チャンネルから提供される「Snaps」のみを「Ubuntu」に含める方法です。
ただし「Confinementポリシー」に「devmode」が設定されている「Snaps」は「stable」チャンネルに配置できないため、結果的に「strict」及び「classic」が設定された「Snaps」のみ含められるようになるでしょう。
またイメージに含まれる「Snaps」は、「Ubuntu」のシリーズごとに用意されたブランチを参照してインストールします。
このブランチに「Snaps」を公開することで前方互換性を確保し、もし「Snaps」が「Ubuntu」の新しいバージョンと互換性が無くなっても、事前のメンテナンスを行わずに済みます。
メンテナー
「Ubuntu」の公式リポジトリーに配置される「debパッケージ」は、アップストリームである「Debian」から同期されるか、「Ubuntu」の開発者によってアップロードされます。さてイメージに含まれる「Snaps」では、アップストリームか「Ubuntu」の開発コミュニティーが管理します。
後者では、Ubuntu SecurityチームやMOTUチームなど「Ubuntu」の関係者がお互いに足並みを揃えられるように、共通のチームを作成します。
ソースコード
「Snap Store」では「Launchpad」と異なり、バイナリーのみの「Snaps」を直接「Snap Store」にアップロードすることができます。デフォルトでインストールされる「Snaps」に関しては、「Launchpad」のインフラを利用しソースコードからパッケージをビルドする仕組みを適用します。
こうすることで「Ubuntu」側で「Snaps」の再ビルドが必要になった時にパッケージの再ビルドを行ったり、「Snaps」が無くなったとしても継続的に「Snaps」の構築が可能になります。
つまり「Ubuntu」が主体的に管理できるようになります。
もちろん「Snaps」がそれを許容するライセンスである必要があります。
ライセンス
「Snaps」で提供されるアプリのライセンスは様々です。デフォルトでインストールされる「Snaps」は「debパッケージ」と同様に「main」や「restricted」のライセンスと同じライセンスを当てはめます。
ただし特定のパートナー向けのイメージやフレーバーでは、関係者の合意の上、上記のポリシーに当てはまらない「Snaps」が含まれる可能性があります。
セキュリティーサポート
デフォルトでインストールされる「Snaps」は、適切なセキュリティーサポートが継続的に提供可能かどうかUbuntu Security Teamによる確認を行い、「debパッケージ」で適用されているプロセスと同等のプロセスを当てはめます。また「Ubuntu」のエンジニアリングチームにより、CVEの提供を行います。
「Snaps」のアップストリームは、脆弱性の修正を安定版にバックポートするのか、新しいバージョンを提供するのか、方法も含めた判断を行えるようにします。
もし「Snaps」のメンテナンスをアップストリームではなくUbuntuのコミュニティーが主体的に行っている場合、バックポートによる修正を推奨します。
