Ubuntu 16.04の新パッケージ形式「Snap」が変えるソフトウェアインストールの未来

UbuntuのLTS（長期サポート）版には、あるトレードオフが存在します。メジャーバージョンアップは2年ごとに行われ、その間はシステム構成が安定したまま、セキュリティアップデートだけを受け取り続けられます。通常リリースのように9ヶ月ごとのアップグレード作業から解放されるのは大きな魅力です。

しかし、その一方で最新バージョンのソフトウェアをインストールしようとすると、壁にぶつかります。システムのライブラリが古いため、動作しないケースが多いのです。

これはLTSやUbuntu特有の問題ではありません。最先端のコードを採用するディストリビューションでさえ、次のリリースまでには陳腐化してしまいます。さらに、一部のソフトウェアは公開時期にかかわらず、公式リポジトリに収録されないこともあります。

Ubuntu 16.04では、この「安定性」と「最新性」のジレンマを解消するべく、新しいパッケージ形式「Snap（スナップ）」が導入されます。従来のdebパッケージに加えて、Snapも選択肢に入るのです。

Snapとは何か？

Snapパッケージは、アプリケーションのバイナリ本体に加え、実行に必要な依存ライブラリまでひとつのパッケージにまとめたものです。その起源は、CanonicalがUbuntu Touch向けアプリの配布のために開発した「clickパッケージ」にさかのぼります。

Ubuntu 16.04では、Snapはテクノロジープレビューとして提供されます。クラシックデスクトップとUnity7インターフェースの中核は引き続きdebが担い、clickパッケージはUnity8（こちらも現時点ではテクノロジープレビュー）の標準フォーマットとして残ります。16.04は、将来的により深く関わっていく前に、まずSnapという技術と顔見せする段階と捉えるとよいでしょう。

Snapの6つのメリット

CanonicalはSnapを「すべてのUbuntuデバイス向けの次世代アプリ形式」と位置づけています。注目すべきポイントを順番に見ていきましょう。

1. ソフトウェアへ速く簡単にアクセスできる

Snapが普及すれば、開発者はUbuntuユーザー向けにPPA（個人パッケージアーカイブ）を用意する必要がなくなります。ユーザーは単一のパッケージをダウンロードするだけで、自分のシステムで動作することを確信できます。意味のよくわからないコマンドラインをターミナルにコピー＆ペーストする手間もなくなります。

これはアプリケーションだけの話ではありません。GNOMEやKDEといったデスクトップ環境の新版へのアクセス改善にもつながる可能性があります。

2. 長期的な信頼性

Linuxのデスクトップ環境やライブラリは変化が激しいものです。その結果、2012年に動いていたソフトウェアが、4年後の同じマシンでは動かない――そんな事態も珍しくありません。古いバージョンのFirefoxをインストールしようとしても、まず成功しないでしょう。

これは開発者にとって頭痛の種であり、Linux向けソフトウェア開発をためらう一因にもなっています。一度アプリを作っても、1年後・2年後も動き続けるよう定期的な修正が必要です。ディストリビューションごとの差異まで考慮すれば、負担はさらに膨らみます。

Snapパッケージは依存関係を内包しているため、アプリは今日も明日も、そして数年先も動くために必要なものをすべて持っていることになります。

3. 分離とセキュリティ

Snapパッケージはシステムの他の部分から独立して動作します。そのため、インストールが既存の環境に影響を与える心配がありません。また、開発者が脆弱性にパッチを当てれば、修正版を即座にユーザーへ届けることができます。

ただしこれは諸刃の剣でもあります。同じ依存ライブラリのコピーが複数存在することになるため、問題が発覚した際にはそれぞれ個別に更新が必要です。もし開発者の一人が更新を怠れば、脆弱なままのバージョンが残ることになります。従来であれば、ディストリビューションのセキュリティアップデートによって一括修正されていた部分です。

4. 有料ソフトウェアのサポート

お金を払ってアプリを購入したら、それが動くのは当然と考えるでしょう。ところがLinux向けソフトウェアの販売は、これが難しいのです。複数のディストリビューションをサポートし、しかも各ディストリビューションは半年ほどの周期で予測不能な変化を遂げていくわけですから。

Snapパッケージを使えば、開発者は「このバージョンなら確実に動く」という状態を保証できます。すべての環境で同一のパッケージが走るため、トラブルシューティングも格段に容易になります。

こうした理由から、Canonicalは同年秋までに有料アプリケーションをSnapへ移行する計画を発表しています。

5. 慣れ親しんだ開発体験

モバイル市場の台頭は、ソフトウェアの開発・配布のあり方に対する期待値を大きく変えました。Google Play、Apple App Store、Windows Storeなど、マーケットごとの細部は異なりますが、基本的な流れは共通しています。パッケージを作成し、審査のために配布センターへアップロードする。CanonicalがSnapのビルドとパッケージングのために提供するツール「Snapcraft」は、Ubuntu開発者にも同様の体験をもたらします。

6. ロールバックできる

アップグレードが常に計画通りに進むとは限りません。新しいバージョンがバグを抱え、使い勝手を損なうこともあれば、最悪の場合アプリが起動しなくなることもあります。そんなとき、開発者は更新を取り消せますし、ユーザー側も以前正常に動いていた旧バージョンのSnapを再インストールするという選択肢があります。

他のディストリビューションへの影響は？

Snapの開発者たちは、Unity上で動作するようこのフォーマットを設計しました。技術的には他のディストリビューションでも動作可能ですが、Unityそのものと同じく、Ubuntuエコシステムの外で広く採用される可能性は低そうです。

とはいえ、この動きは類似の代替フォーマットへの関心を呼び起こすかもしれません。その代表例がAppImageです。AppImageは今すぐLinuxデスクトップで利用でき、Atom、Blender、Chromium、Firefox、VLCなど多数のアプリが提供されています。

AppImageは2006年登場の「Klik」の系譜に連なるプロジェクトです。類似の試みはほかにもあり、Klikから派生したPortableLinuxAppsは、USBフラッシュドライブから直接起動できるソフトウェアを実現してきました。

Snapが他のディストリビューションに普及するかどうかにかかわらず、この流れは「ディストリビューションに依存せず、依存関係の問題も抱えないパッケージ形式でアプリを配布する」という開発者文化を後押しするかもしれません。理想はそうですが、現実がどのような形を取るかはまだわかりません。

Snapは良いニュースになり得る

Linuxへのソフトウェアインストールは、ときに骨の折れる作業です。リポジトリにあれば話は早い。なければ、開発者が自分の使っているディストリビューション向けの導入方法を用意してくれていることを祈るしかありません。プロジェクトごとにアプリ管理やアップデートの手法が異なる以上、すべてをサポートするのは困難です。ただし現時点では、Snapシステムがセキュリティリスクとなり得る点にも留意が必要です。

Ubuntuはこの課題にどう向き合うべきでしょうか？Snapの登場を楽しみにしていますか？他のディストリビューションについてはどうでしょう？どんなパッケージ形式を採用すべきだと思いますか？意見が分かれるテーマですが、あなたの考えを聞かせてください。

画像クレジット：conveyor belt by Vivi-o via Shutterstock