snapはCanonicalとUbuntuコミュニティが開発・推進している「ユニバーサルパッケージ」です。いわゆるLinuxディストリビューションを問わずに利用できるパッケージフォーマットであり，強力な権限管理機能を備えています。今回はこのsnapを，Ubuntu以外のディストリビューションにインストールしつつ，コンテナ管理システムであるLXDのsnap版パッケージをインストールしてみましょう。

snapはいろいろなディストリビューションで利用可能

snapはCanonicalとUbuntuコミュニティが推進する「ユニバーサルパッケージ」です。依存するソフトウェアをすべてパッケージに含めることで，依存関係を気にせずあらゆるディストリビューションでインストール可能なバイナリパッケージとして利用できます。

まずはsnapを説明する上で出てくる用語を整理しておきましょう。ごたくはいいからインストール方法を知りたい人は「ディストリビューションごとのインストール方法」までジャンプしてください。

• 「snap」はパッケージフォーマットであり，またコマンド名です。
• snapパッケージをインストールする上でシステムに必要になるのがデーモンサービスである「snapd」です。
• snapパッケージを構築するツールが「snapcraft」です。
• snapパッケージを配布するリポジトリサービスを「Snap Store」と呼びます。

開発者はsnapcraftで構築したsnapパッケージをSnap Storeにアップロードします。Snap StoreへのアップロードはUbuntu Oneアカウント（Launchpadアカウント）だけあれば十分です。AndroidのGoogle Playと同様に誰でも任意のソフトウェアをアップロード・配信できます。将来的には有償配信にも対応する予定です。

利用者はsanpdをシステムにインストールした上で，snapコマンドもしくはUbuntuソフトウェアアプリからsnapパッケージをインストールします。既存のパッケージ管理システムに対して，snapは次のような機能が備わっています。

• 1つ前のバージョンへのロールバック
• 複数のリリースブランチの配信機能（channel）
• AppAprmor/seccomp等を利用したホストに対する隔離機能
• 細かい権限管理（interface）
• 複数のバージョンの並行利用

一部は他のユニバーサルパッケージでもできたり，ものによっては既存のパッケージ管理システムでもできるものもあります。ただしすべてをひとつのソフトウェアで実現可能なのはおそらくsnapだけでしょう。

ちなみに複数バージョンの並行利用は比較的最近に実験的に実装された機能になります。同じシステム上で同じソフトウェアの異なるバージョンを使い分けたいときに便利です。

最近はいろいろなソフトウェアがsnapで配信されるようになってきたので，本連載でもたびたびsnapパッケージのインストールを紹介しています。代表的になのはLXDですが，第499回のShotCutや第560回のmicrok8sなどがそれに該当しますね。第515回にも紹介されているように，最近のUbuntuではいくつかのGUIアプリについてはsnap版がインストールされるようになりました。また，第476回ではsnapパッケージの作り方が紹介されています。

なお，UbuntuデスクトップやUbuntuサーバーにおいてdeb/APTをすべてsnapで置き換える予定は今のところありません。これはsnapとdeb/APTで目的やターゲットが異なり，それぞれできること・できないことがあり，得意不得意な部分が異なるためです。Debianパッケージを簡単にsnapパッケージにする仕組みは存在するものの，あくまでそれはsnap化に向いているパッケージのみの仕組みであり，Debianパッケージをすべてsnap化しようとすると多大な労力が必要になる割に，得られるものはそこまで多くないでしょう（※1⁠）⁠。

※1

インストールするものが限定的なIoT向けには，snapオンリーの環境を提供しています。

更新頻度の高い，単独のCLI/GUIアプリなどはsnap化に向いています。それに対して，いろいろなアプリケーションからライブラリ的に使われるようなソフトウェアはDebianパッケージ化したほうが皆が幸せになれるでしょう。

なぜユニバーサルパッケージなのか

Linuxディストリビューションを使用している人の大半は，個々のディストリビューションのパッケージ管理システムにお世話になっていることでしょう。特に依存関係まで含めて必要に応じてインストールやビルドを行ってくれるその仕組みは，ソフトウェアの再配布やソースコードの取得の自由が保証されているFLOSSで構築されているがゆえの利点であるとも言えます。

ただし一般的に異なるパッケージ管理システム同士に互換性はありません。そもそもパッケージ名の命名ルール自体が異なります。さらにバイナリ配布がメインとなっているパッケージ管理システムのほとんどは特定のパッケージに対しては特定のバージョンのみインストールできる仕組みです。結果として，次のような問題が起こりえます。

• 特定のディストリビューション・パッケージ管理システム向けにしか提供されないソフトウェアがある
• 同じソフトウェアでもディストリビューションごとて提供されるバージョンが異なる
• あるソフトウェアを構築する際に必要なライブラリなどのバージョンがとても古い

いずれも利用者が自分自身で解決できる問題ではあるものの，手間はそれなりにかかります。さらに大変なのはLinux向けのソフトウェアを開発する側です。もし最新バージョンのバイナリパッケージをリリースするのであれば，各ディストリビューションのリリースごとのパッケージ・バージョンの違いを意識しながら構築しなくてはならないからです（※2⁠）⁠。

※2

見方を変えると，各ディストリビューションのパッケージメンテナがこの「大変な部分」を肩代わりしていると言えます。

UbuntuであればPPAが活用できます。それなりに体力があるところは，RHEL/CentOS系とDebian/Ubuntu系のそれぞれの独自リポジトリを構築して提供しているかもしれません。ディストリビューションのパッケージに依存せずに利用できるソフトウェアであれば，特定の言語のエコシステムを利用する手もあるでしょう。

どの方法もどうしても開発側に「ディストリビューションごとのパッケージング」の知識が必要になってしまいます。結果的にソフトウェアごとに「提供するディストリビューションが異なる」状況が発生する状態です。ユニバーサルパッケージはそのような状況を打破するために作られました。たとえばsnapパッケージを作りたいのであれば，snapcraft.ymlという名前のファイルに必要な情報を埋めるだけです。ビルド自身はDockerやLXDのコンテナの中で実行可能です。

といっても考え方自体はそこまでものでもありません。たとえばユニバーサルパッケージ的な機能を備えたAppImage（旧称klik）は2004年のリリースです。

今だとsnapと双璧をなすFlatpak（旧称xdg-app）もユニバーサルパッケージを実現する存在です。FlatpakはどちらかというとGUIアプリケーションをメインターゲットとしていますが，こちらも開発は活発なのでいずれCLIでのUXも改善することでしょう。第513回でも紹介しているように，Flatpakで提供されているソフトウェアは増えています。