次世代パッケージ管理システムあれこれ

パッケージ管理システムとは

Windowsのパッケージ管理システム

Windowsでは馴染み薄いけれども、早い話が「アプリケーションをインストール・アンインストールする際に各種ライブラリなどの依存関係をいい感じに処理してくれるシステム」のこと。

パッケージ管理システムでアプリケーションのインストールなどをするようになると「アプリケーションの配布ページにアクセス→ダウンロード→インストール」という3つの手順が「パッケージインストールコマンドを打つ」という1つの手順だけで済むようになるので非常に楽。

Windowsの場合はユーザの見かけ上は馴染みが薄いだけでWindows8以降ではMicrosoft StoreからインストールできるUniversal Windows Platform(UWP)アプリはパッケージ管理システムを経由してインストールされていると言って間違いないはず

それ以前にもChocolateyやScoopなどのWindows向けパッケージ管理システムは存在しており、プログラマを代表とする情報技術者は使っている人が多いと思う。

Macのパッケージ管理システム

MacユーザであればMacPortsやHomebrewはほぼ当たり前のようにインストールするパッケージ管理システムなのではないかと。

ハードウェアに依存しているけれどもPOSIXな設計のOSとして情報技術者にも人気が高い。

現在のパッケージ管理システムの問題点

現在のパッケージ管理システムには大きな問題点が1つある。

それは導入しようとするアプリケーションの依存関係にライブラリの更新が必要な場合、依存するライブラリは上書きアップデートされるというもの。

もしこのライブラリが下位互換を持たないとき、他のアプリケーションが古いライブラリを使用している場合、他のアプリケーションが動作不能に陥る可能性がある。

依存するライブラリの理想としては完全な下位互換があるべきだけど、例えばPythonやRubyなどの非後方互換性は有名で、更新によるアプリケーションやサービスの沈黙を経験した人は少なくないはずだ。

次世代パッケージ管理システムはこの問題点を解消すべく動き始めた。

4つの次世代パッケージ管理システム

現在の次世代パッケージ管理システム開発は競争の状態にあり、代表的なものに「Nix(Guix)」「AppImage」「Flatpack」「Snappy」がある。

Nix(Guix)

次世代型パッケージ管理システムと言っても、その言及は思ったよりも古く、固有名詞のパッケージ管理システム名として正式に最初に登場したのは2004年の「Nix」だった(Guixは2012年に登場したNixのGNU実装)。

インストール先とバージョン管理

Nix(Guix)の最大の特徴はインストールするパッケージは/usr/binなどへ一意にインストールされるわけでなく、その固有のディレクトリにインストールされるということ。

これはバージョン違いの同一アプリケーションパッケージであっても同様で、例えばPython2.xとPython3.xは別の固有ディレクトリへインストールされる。

これらの管理はパッケージ毎にハッシュ値が与えられており、ユーザは任意にバージョンをローカルでロールバックできる。

パッケージのアンインストール

ユーザがパッケージをアンインストールしようとするとNix(Guix)はハッシュ値を元に問い合わせ依存関係のないバージョンのライブラリパッケージのみアンインストールする。

マルチユーザ

パッケージは固有のディレクトリへインストールされるので管理者権限が必要なく、各ユーザは安全(セキュアという意味でなく)にパッケージをインストールできる。

欠点

各バージョンのパッケージが固有のディレクトリへインストールされるということは、つまりそれだけ多くのストレージを消費するということに他ならない。

パッケージファイルはバイナリファイルなので、テキストベースでできているプログラムソースコードのような差分バージョン管理は難しく、各バージョンのパッケージを丸々バックアップする他ない。

例えば、ソースコード管理定番のGitもイメージファイルなどの大きなバイナリファイルは差分管理しているわけでなく、Git LFSによって丸々バックアップしている。

ただ、昨今のストレージ容量の進化を見ると大きな問題になりにくいとは思うが、組み込みなどストレージ容量に限界があるときは大きな問題になるだろう。

ちなみに正式にMacもサポートしている点は着目すべきかも知れない。

AppImage

AppImageは正確に言うとパッケージ管理システムではない。しかしそのシステム上、次世代パッケージ管理システムと似たような振る舞いができるので取り上げる。

名称の変移

最初期の言及はNixと同様に2004年と古く、当時「Kilik」と呼ばれた。2011年には「PortableLinuxApps」と改称し、2013年に「AppImage」と改称した。

改称しても開発自体は一貫として行われている。

インストールしない

AppImageの最大の特徴はLinuxシステムから見て、インストールしていない状態でアプリケーションとして扱えることにある。

2011年の「PortableLinuxApps」という名称から判るように設計思想としてはポータブル向けのもので、USBメモリなどで持ち運んで様々なLinuxディストリビューションで扱えることを目的としている。

インストールが必要ないので当然ながらマルチユーザにも対応している。

ライブラリを同梱する

通常のアプリケーションはLinuxディストリビューション毎に最適化されたバイナリパッケージが必要であるが、Linuxディストリビューション毎にアプリケーションの動作させるために必要なライブラリのディレクトリが微妙に違ったり、ライブラリのバージョンが適合していない可能性がある。

AppImageはLinuxシステムから見てインストールしないという振る舞いをするため、そのアプリケーションを動作させるために必要なライブラリを同梱させ、上記の障害を回避するように努めている。

ただ例外もある。それは例えばX Windows Systemなど多くのLinuxディストリビューションへまず導入されているであろうライブラリ群は同梱しないことがある。

AppImageのバージョン管理

AppImageはそれぞれが非常に独立性の高いパッケージなので、バージョン管理はパッケージバイナリをまるごとディレクトリなどで分類させることが現実的な管理方法となる。

これをバージョン管理というには些かスマートさに欠けるが、次世代パッケージ管理システムの多くもパッケージバイナリをバージョン毎にまるごと保存する手法が取られているのでコンセプトとしては非常に近い。

AppImegeと次世代パッケージ管理システムの最大の違いはアップデートさせるシステムやバージョン管理するようなツールがないこと。

多くの読者も感じているだろうが、AppImageはWindows界のインストールを必要としないアプリケーションのアップストリーム運用に近いものとなる。

欠点

欠点はNixと同様にバージョン毎にパッケージが独立して存在しているのでストレージ容量を圧迫するということ。

Nixと比較してもライブラリを同梱するという方針もあり、Nixよりもパッケージサイズが大きくなる可能性が高い。

更にアプリケーションの拡張子による関連付けができないので、MP4を選択したときにAppImageな動画プレイヤを候補表示するといったことが難しい。

Flatpack

Flatpackは実行環境を隔離して動作させる仮想環境を用いたパッケージ管理システム。

アプリケーション専用

Flatpackの最大の特徴はアプリケーション専用だと言うこと。このアプリケーション専用とは事実上GUIアプリケーション専用のようなもので、より大衆的なユーザビリティを目指して開発されているような印象を覚える。

サンドボックスとランタイム

Flatpackは実行環境を隔離して動作させる仮想環境を用いたパッケージ管理システムで、パッケージインストールに伴うLinuxシステムや他のアプリケーションへの影響を最小限に留めることができる。

サンドボックス上で動作するアプリケーションは、ライブラリとコマンドが内包されたランタイムを参照して動作する。

このランタイムは例えばPython2.xとPython3.xなどの違いを持ち、Flatpackは適切なランタイムを選択しアプリケーションを適切に動作させる。

インストールとアップデート

Flatpackのインストールとアップデートもランタイムを参照し、必要なランタイムがインストールされていなければリモートリポジトリへ問い合わせ、リモートリポジトリに必要なランタイムが存在しなければインストールやアップデートを実行しない。

アプリケーションの安定動作を考えるのであればFlatoackは非常に良い設計思想を持つということになる。

バージョン管理とOSTree

FlatpackのリポジトリはOSTreeで実装されており、OSTree側のバージョン管理機能で古いビルドを呼び出すことができる。

これは他の次世代パッケージ管理システムのように固有のディレクトリへアプリケーションのバイナリを保存しておくという手法ではないので、ストレージ容量的には有利だ。

ただ正直なところ、ここまで大衆的なユーザビリティを目指して開発されているのにも関わらずバージョン管理だけは従来通りのOSTreeのコマンドを打たなければならないのは少々釈然としないけど、大衆的なユーザはそこまでアプリケーションのバージョンを行き来しないので別に良いのかも知れない。

GitもGUI関連は最近やっとまともになってきたので時間が経てば解決する問題かも知れない。

Snappy

昨今人気の高いLinuxディストリビューションUbuntuを開発しているCanonicalが推している次世代パッケージ管理システム。

最近のCanonicalのSnappyに言及した文書には「Snaps」と表記してあるので、もしかしたらSnappyからSnapsに改称したのかも知れない(改称した宣言が見当たらないんだけど・・・?)

Snappyのサンドボックス

SnappyもFlatpackと同様にサンドボックス内でアプリケーションを動作させる設計。

Snappyにはアプリケーションを動作させるためのライブラリ群もパッケージ内に含まれており、その点で言えばAppImageのアプローチに近い。

ただし、AppImageのようにLinuxシステム上からインストールされていないという振る舞いではないので、拡張子からの関連付けは可能。

チャンネル

Snappyの特徴として「チャンネル」と呼ばれる複数のリポジトリの存在がある。

これは難しいことは何もなく、内容は「stable(安定版)」「candidate(安定版の候補)」「edge(非安定版)」「beta(betaテスト版)」ということで、既存のパッケージ管理システムにも似たようなリポジトリ群を用意している場合が多々あるので迷いは少ないかもしれない。

これらのリポジトリの同一名アプリケーションは切り替えて使用することが可能。

ちなみにGUIからもチャンネルの切り替えができるので大衆的なユーザビリティも考えられている。

バージョン管理とリビジョン

Snappyは古いパッケージをリビジョンとして管理しており、リビジョンを指定することによって古いパッケージをインストールすることが可能。

範囲

SnappyはFlatpackよりも扱う範囲が広く、アプリケーションのみでなくライブラリやLinuxカーネルまで扱う範囲として考えられている。

同様の範囲を持つのはNix(Guix)で、Snappyはこれまで考えられてきたパッケージ管理システムの良いとこ取りをしようという意図が感じられる。

欠点

例に漏れずストレージ容量を圧迫する傾向がある。

そして最大の問題として挙げられているのは移植性の問題。

Snappyは現在多くのディストリビューションをサポートしているが、事実上安定して動作しているのは本家本元のUbuntuのみであり、他のLinuxディストリビューションでは何かしらの問題を抱えている状況がある。

SnappyはUbuntuで使うのであれば非常に良くできており、コマンドもわかり易く快適なパッケージ管理が行えるが、Ubuntuだけしか上手く使えないという現状がどう変わっていくのか注視していく必要があると思う。

色々書いたけれど

つまるところ、次世代パッケージ管理システムは安定した依存関係の解消と、その解法にバージョン管理システムを選択しているというのが特徴。

それぞれに微妙な特色と差異があり面白く、これらの知識を得ると使い慣れた既存のパッケージ管理システムが古く感じて「そうなんだよね依存関係の兼ね合いでシステムが汚れちゃったりとかさぁ・・・」みたいな不満が出てしまう。

次世代のバージョン管理システムは提案から数えると15年以上はずっと検討されている題目で、最近やっとユーザが使えるシステムとして動き始めた段階。

練れ親しんだAPTやRPMやPacmanなどが、もしかしたらMacPortsとHomeBrewみたいな関係性になるかも知れないと思うと少し胸が熱くなるのはボクだけだろうか?

蛇足

当初この話題、グルドンへ思いっきり連投してやろうかと思ったけれど、ふと冷静になり「間違いなく長文になってマストドンでやる話じゃないw」と自重してブログにすることにした経緯がある。

文章の作りとかそういうの無視して書きたいことを書き殴ったので乱文乱筆だったでしょうが、ここまでお付き合い頂き感謝しかないです。

もしこの話題にご興味があればどうぞグルドンで話しかけてやって下さい。皆さんはどのパッケージ管理システムを応援しますか?

ではでは!