ユニバーサルパッケージとは

最後にsnapパッケージやそれに類いするパッケージフォーマットで言及されることの多い，ユニバーサルパッケージについて説明しておきます。

「ユニバーサルパッケージ」とはLinuxディストリビューションに依存しないパッケージの俗称です（※5⁠）⁠。簡単にまとめると「LinuxシステムにAndroidやiOSのようなパッケージ管理機構をもたらすもの」と言えます。

※5

ユニバーサルパッケージはsnapやflatpakを説明する文脈でよく使われる言葉ではありますが，必ずしも明確な定義があるわけではありません。

歴史的経緯から，Debian系ならAPT/dpkg，RHEL系ならDNF/YUM/RPMなど，openSUSE系ならZypper/RPMなど，Linuxにおいてソフトウェアパッケージとその管理システムはディストリビューションに強く紐付いています。結果，ソフトウェアデベロッパーがバイナリパッケージを提供しようとすると，ディストリビューションごとのパッケージ作成方法を学ばなくてはなりません。結果として，ソースコードを配布しつつ開発者の好みのディストリビューションのみバイナリパッケージが提供されていることもよくあります。

パッケージングにおいて最もネックになるのが「依存関係の解決」です。特定のソフトウェアをビルドするためには，別のソフトウェアが必要であり，実行時にはさらに別のソフトウェアが必要になる，そんな依存関係を逐一解決しながらパッケージを作る必要があります。しかもその依存関係はソフトウェアの修正や，ディストリビューション側の変更によって随時変わっていきます（※6⁠）⁠。

※6

Debianだと1994年1月に公開された0.91には，パッケージ管理スクリプトとして「dpkgコマンド」を同梱していました。当時はコンパイル済みバイナリを展開するただのシェルスクリプトでした。ちなみにこのdpkgコマンドには「StopALOP」と呼ばれるパッケージングシステムにインスパイアされたものと書いてあります。意味は「脱毛症の阻止⁠」⁠。つまりソフトウェアのインストールは，当時から毛髪に優しくない作業だったようです。

そんな状況を打破するために考えられたのが「ユニバーサルパッケージ」という概念です。フォーマットによって多少違いはあるものの，おおよそ次のような機能を備えたものになります。

• ディストリビューションをまたいで，同じバイナリパッケージをインストール可能
• 依存関係は原則存在せず，必要なものはすべてパッケージの中に取り込んだ状態で提供する
• サンドボックス化によるセキュリティの向上と，ディストリビューションとアプリケーションの分離の推進

ソフトウェアは多かれ少なかれ何らかの別のソフトウェアに依存しています。Linux上で動くELFバイナリであれば，最低限libcやリンカー・ローダーに依存しているでしょう。Pythonなどのスクリプト言語はそれぞれの処理系に依存しているはずです。これらはディストリビューションやそのリリースごとに異なるバージョンを採用しています。つまり「あるバージョンでは動く」ソフトウェアであっても，別のバージョンでは動かないことがままあります（※7⁠）⁠。

※7

そもそもの話として「バージョン」の定義も曖昧です。たとえばアップストリームでは新しいバージョンにのみ適用されているパッチが，ディストリビューションのパッケージでは古いバージョンにも適用されていることはよくあります。脆弱性情報で「xx以降のバージョンで解決済み」と表記されているとき，必ずしもそれをそのままパッケージのバージョンと比較するわけにはいかないことに注意が必要です。

また「依存関係の解決方法」はディストリビューションごとに異なります。Debianならパッケージ「FOO」さえインストールすれば動いていたものが，RHELなら「BAR」と「BAZ」の両方が必要ということもよくあります。また，コンパイル時のオプションを変える必要もあるかもしれません。

結果として任意のバイナリパッケージは，ディストリビューション・リリースごとに異なるパッケージデータになることが一般的です。

ユニバーサルパッケージでは，原則として依存するものをすべてひとつのパッケージの中に取り込みます。これにより「Linuxカーネルとパッケージ管理システムが動いているシステムならどこでも利用可能」で「気軽にインストール・アンインストール・ロールバックが可能」なパッケージフォーマットを実現しているのです。

依存関係に基づくバージョンもパッケージを作る側でコントロールできるため，「⁠ソフトウェア開発者が動作確認している組み合わせ」をそのままパッケージとして提供できます。よってバージョン不一致に伴う予期せぬトラブルや，RHELなら問題ないのにUbuntuならエラーになる，といった状況も防げる可能性が出てきます。

しかしながらこれらのメリットを実現するためには，次のようなデメリットも発生します。

• パッケージサイズが大きくなる
• ライブラリとの柔軟な組み合わせができない
• パッケージ管理システムそのものの複雑性が増える
• サードパーティのパッケージの利用に対する是非

ディストリビューションのパッケージは，そのディストリビューションをよく知っているメンテナーがパッケージを作成・管理しています。これにより柔軟かつ一貫性が保たれたパッケージを提供できていました。普段のLinuxマシンには多種多様なソフトウェアがインストールされているにも関わらず，アップグレード時に「多少のトラブル」で済んでいるのが，その証左でしょう。

この品質の高さが従来のパッケージ管理システムの強みであり，ユニバーサルパッケージで実現するのが難しい部分です。結果的に，従来のパッケージとユニバーサルパッケージは，相補的に共存する方向性を目指しているように見えます。

• ソフトウェア開発者：ユニバーサルパッケージフォーマットを用いて，常に最新のディストリビューションに依存しないパッケージを提供する
• ディストリビューター：従来のパッケージフォーマットを用いて柔軟に組み合わせ可能で，なおかつディストリビューションの中において一貫性の高いパッケージを提供する

ユーザーは用途に応じて2種類のパッケージを使い分けることになります。まず，最新の確実に動くパッケージがほしいならユニバーサルパッケージを使うと良いでしょう。それに対して複数の異なるパッケージのバージョンを指定したり，Dockerイメージの中で使いたいなら従来のパッケージのほうが柔軟な組み合わせが可能になります。

Snap以外のユニバーサルパッケージ

さて，そんな「ユニバーサルパッケージ」ですが，現在広く使われているパッケージフォーマットとして次のようなものが存在します。

Nix

おそらくユニバーサルパッケージ的な考え方の先駆けとも言うべき存在で，2000年代前半から存在していたようです。

AppImage

これも比較的早くから存在していた仕組みで，アプリケーションをISOイメージに閉じ込めることで，「⁠パッケージ管理」が不要になっています。

Flatpak

FedoraおよびRHELが強力に推進しているフォーマットで，今のところGUIアプリケーションをメインターゲットにしているようです。

Snaps

Ubuntu/Canonicalが推進しているフォーマットです。他と比べると強力な権限管理機能が売りとなっています。

Docker

言わずとしれたコンテナプラットフォームの主役です。最近は任意のアプリケーションの実行環境としての地位も確立しているため，DockerHubて配布されているコンテナイメージはある種のユニバーサルパッケージと言えるでしょう。

Flatpakについては第513回の「新しいパッケージの仕組み，Flatpakを使用する」を参照してください。AppImageもスタンドアローンなアプリにおいて採用例はそれなりに存在します。Nixはすでにある程度のエコシステムを構築しているため，NixOSをはじめとしてそれらのエコシステムをメインにするのであれば選択肢に入ってくるでしょう。

今回紹介したSnapsは，Ubuntuで最初から使えるようになっていますし，第582回の「いろいろなディストリビューションでsnapとLXDを利用する」を参考にすれば，他のディストリビューションでも利用可能です。Flatpakと比べると，将来性にはまだ不安要素が残っているものの，Ubuntuで生活するならSnapを使うほうが楽なケースは確実に増えています（※8⁠）⁠。

※8

Fedora/RHELが推進していることからもわかるように，ここだけの話「将来主流になる可能性が高いほう」という観点だとSnapsよりはFlatpakに分がある印象です。Flatpakはサーバー向けやCLIツールには弱いですが，そちらはDockerをはじめとするCRI準拠の各種ランタイムが覇権を握りつつあります。

たとえばLXD，Nextcloud，Microk8sなどのサーバー向けのサービスはsnapパッケージとしてインストールするほうが簡単ですし，Chromiumなどの更新頻度の高いデスクトップアプリケーションもsnapパッケージとして提供されています。

IoTからサーバー，デスクトップに至るまで統一的に利用できるのがSnapsの強みです。この強みが本当に活かせるかどうかは，まだ数年以上の経過観察が必要になるでしょう。