過去から振り返るLinuxの次世代パッケージ管理の話

こんにちは。今回のテーマは「過去から振り返るLinuxの次世代パッケージ管理の話」です。Linuxディストリビューションにとってパッケージ管理は大きなテーマの１つです。ソフトウェアやライブラリのインストールや削除する際の依存関係をどのように解決するのか様々な試行錯誤が繰り返されてきました。今回は大雑把に過去のパッケージ管理を振り返りながら新たに登場し、実用的になってきた新タイプについて見ていきたいと思います。いつものハウツー記事ではないのでコーヒーブレイクにどうぞ！

【目次】
パッケージ化以前のお話
 過去から現在までのお話
 従来型のパッケージ管理の弱点
 従来型のパッケージ管理の弱点
 より身近になった新時代のパッケージ管理
 さて今後は？

パッケージ化以前のお話

今でこそ、Linuxのソフトウェアはパッケージ単位で配布され、パッケージマネージャーでコマンド１つで簡単にインストールされるようになりましたが、パッケージ形式の配布が確立される以前は、インストール作業とはユーザーが自らソースコードからビルドして適切なディレクトリにバイナリや設定ファイルを配置することでした。いまでもパッケージ化されていないソフトウェアは、この方法で自分でインストールする必要があり、まったく過去の話という訳ではありませんが、体感としては少なくなったと思います。パッケージが普及した今では、仮にソースコードからビルドする場合も、一度パッケージを作りインストールするという方法をとる場合も多いと思います。

過去から現在までのお話

ソフトウェアを使う度にビルドしてインストールする。この状況を打破すべく様々なソフトウェアのインストール方法が考え出されました。パッケージ管理には様々な考え方や哲学があり、さまざまなディストリビューションが存在する１つの理由はパッケージ管理方法が異なる故とも言えます。

ソースコードからのビルドを自動化するという選択肢

どうせソースコードからビルドするならば、その工程を自動化すれば良い。そのような考えから生まれたパッケージ管理法はFreeBSDのPortsやGentoo LinuxのPortage等で採用されました。インストールの度にソースからビルドすることでマシンに最適化されたソフトウェアをインストールでき、ビルド時のオプションも渡すことができるというメリットがある一方で、ビルドに長時間かかるというデメリットがありました。

バイナリ配布派たち…DebianとRedHat

一方で、ビルドされたバイナリを配布する方法を模索するグループがありました。バイナリ形式での配布はユーザーがビルド時に細かいチューニングが出来ない一方、バイナリファイルを所定の場所に配置すれば使えるというインストールの短時間化が図れる方法でした。最初はビルドしたディレクトリをtar.gzファイルにまとめて配布するだけの単順なものでした。やがて、依存関係をパッケージに記載し自動で解決する管理方式に変遷を遂げていきます。

Debianではdebパッケージの管理システムAPTを確立し、パッケージ間の依存関係を解決したことでdpkgコマンドを打たなくてもapt-getコマンドでユーザーが簡単にアプリケーション導入・削除を行えるようにしてきました。これは当時画期的なことで、Debianの堅牢さと安定性の高さを支える屋台骨となりました。

rpmパッケージは当初、rpmコマンドでインストールすることが主流でした。オンラインからパッケージの取得、依存性の解消まで自動で行ってくれるパッケージ管理ツールも今ほど普及しておらず、依存性は自分で解決してrpmコマンドで各パッケージをインストールしていました。ディストリビューションによってはapt-rpmというDebianのAPTシステムでrpmパッケージを管理できるようにするなど工夫をしていました。やがてYUMやrpmi, YaST等のツールが登場し、現在のRedHat系の多くのディストリビューションのrpmパッケージ管理を支えています。

筆者の主観ですが、90年代末から2000年代、日本国内でLinuxというと多くの場合がRed Hat系であったような気がします。（Vine Linuxが日本語に強かったというのが影響している気がします。）筆者も実際に自分がLinuxに触るまでは「Linuxのソフトは.rpm形式で配布される」と思い込んでおり、Debianに出会ったとき衝撃的だった記憶があります。近年Ubuntuが普及するまで多くのプリンターメーカーがドライバをrpm形式で配布していたのも、そのような事情によるものかと思っています。

従来型のパッケージ管理の弱点

これら従来のパッケージ管理方法には弱点がありました。複数のアプリケーションから必要とされる共通のライブラリはバーションを統一する必要があります。つまり、特定のアプリケーションだけ最新版を使いたくなり、それに依存するライブラリ等のバージョンを上げると、それに引きずられ他のソフトウェアのバージョンも…という具合に雪崩現象が起きてしまいます。よって現在はディストリビューション側で依存するライブラリやソフトウェアのバージョンも含めて全体が最適化されるよう管理されており、ユーザーが好きなバージョンのソフトをインストールして使うことは（パッケージ管理の観点からは）できないという不便さがありました。

また、ディストリビューションによってコマンドが違うという問題もLinuxの大衆化という点では問題になるでしょう。誰もがこの記事を読んでいるような技術好きな方ばかりではありません。家電のようにPCを使いたい方にとってディストリビューション毎に異なるコマンド体系があるというのは混乱を招きます。ディストリビューションを横断したアプリケーションのインストール方法はLinuxの普及と共に必要になってくるでしょう。

そしてNixOSが生まれた

NixOSとはLinuxディストリビューションの１つで”純粋関数型ディストリビューション”を謳って登場しました。NixOSの詳細説明は誌面の都合上省きますが、OSの設定やパッケージの処理が非破壊的でロールバック可能なことを実現する仕組みを持っています。設定に独自の関数型言語Nix言語(Nix Expression Language)を用いることも特徴的なディストリビューションです。このNixOSでパッケージ管理に用いられたのがNix Package Managerでした。とても簡単に言ってしまうとパッケージが依存するライブラリやプログラムがまるごと一意に生成されたハッシュ名のディレクトリに入れて管理されます。パッケージのバージョンが異なる場合は別のディレクトリに格納されます。これによりバージョンの異なるパッケージの共存とパッケージ間の依存関係を解決するのです。このNix Package managerは意外にもMac OSに対応しています。また、このNixをベースにGNU Guixというフリーソフトを提供するパッケージマネージャーが生まれました。GNU Guixはディストリビューションを横断したパッケージマネージャーなので、例えばArch Linuxに導入することもできます。(Arch wikiでは動作は保証しないとなっていますが…)

より身近になった新時代のパッケージ管理

そして近年、NixもしくはGNU Guixと似たような構想を持った新しいパッケージマネージャーがより身近に感じられる存在となってきました。Ubuntuの開発母体であるCanonical社が開発したsnaps(以前はsnappyだった)と、freedesktop.orgのプロジェクトとしてスタートしたflatpakです。この他にパッケージ管理とは技術的に異なるが、ユーザーに似たような体験をもたらす機構としてAppImageが登場しました。

Snaps – Canonical開発のパッケージ技術

snapsはUbuntuの開発をしているCannonical社が開発した技術です。Canonical社はsnapsはUniversal Linux packagesと位置づけており、ディストリビューションに依存せず、自己完結したパッケージを目指しています。後述するflatpakと技術的、思想的に似ており、サンドボックスという仮想化された空間でアプリケーションを動かすことでシステムに依存しないパッケージとなっています。

開発者はSnapclaftというツールを使用してsnapパッケージを作成しストアで公開することができます。ユーザーはsnap installコマンドもしくはブラウザでストアから簡単にインストールすることができます。

サンドボックスで動かすために依存するライブラリやプログラムはすべてパッケージ内に内包されることになります。これによりシステムに依存せず動かすことができるのですが、デメリットとしてパッケージの容量の巨大化という問題が生じます。

また、ディストリビューションに依存しないパッケージ管理システムを謳ってはいますが、Ubuntu以外のディストリビューションでは安定動作しないこともあり、依然Ubuntu用という感は否めないところもあります。これは時が解決するかも知れませんが。

snapsのパッケージはsnapcraftのストアで探すことができます。

flatpak – freedesktop.orgのプロジェクトより生まれたパッケージ技術

仮想化したサンドボックス内でアプリケーションを動かすという点においてflatpakはsnapと似ています。ディストリビューションに依存しない簡単なアプリケーションのインストール方法を提供することを目指すという点も非常に似ています。

ただ、freedesktop.orgのプロジェクトとして発足したためかパッケージの守備範囲はGUIアプリケーションに特化している印象を受けます。システム周りのアプリケーションやライブラリも対象とするSnapsとは一線を画します。

flatpakはOSTreeを使用してデータを配布しています。つまり、flatpakのパッケージのバージョン切り替えはOSTreeのコマンドによって可能となり、バージョンごとにバイナリを別ディレクトリに格納するNix方式のパッケージ管理よりは容量の点で有利になるのではないかと考えます。

flatpakはリポジトリからパッケージを取得する方式で、flathubが公式のリポジトリです。

AppImage – インストールせずにアプリケーションを使うという発想

そもそもAppImageはインストールするパッケージ管理ツールではなく、独立したアプリケーションイメージの管理方法です。従来のアプリケーションはバイナリパッケージがシステムにインストールされ、動作に必要なライブラリや依存アプリケーションに頼って動作していましたが、AppImageはLinuxシステムにインストールされず独立して動作します。

よってAppImageのアプリケーションはディストリビューションにも依存せず、システム内のライブラリ等にも左右されず実行することが出来ます。ユーザーから見れば多様な環境で同一のアプリケーションを動かすということが可能になります。まさにアプリケーションのポータブル化を実現する技術と言えるでしょう。余談ですが、このプロジェクトの初期の頃の名称は”PortableLinuxApps”であったそうですから、まさに目指していたのはアプリケーションのポータブル化ということになります。

デメリットとしては、動作に必要なライブラリ等の環境をまるごと内包してイメージ化しているため、従来のインストール型のパッケージよりも容量を圧迫することです。

さて今後は？

ここまで、新たなLinuxソフトパッケージおよびAppImageというインストールしないでソフトを使用する新たなアプリケーション利用の形を紹介してきました。では、いままで私達が使用してきたapt, yum, pacman, dnf… これらのコマンドは無用となるのでしょうか？未来のことは筆者にも分かりませんが、当面は従来のパッケージ形式と新たなパッケージ形式は並列で使用されると考えています。仮想化を用いるソフトウェア管理は既存のシステムと衝突しないために、共存することができます。おそらく、システムの根幹に関わるパッケージはapt, yum, dnfが支え、ユーザーに近いGUIアプリケーション（オフィスソフトやブラウザ等)はsnapsやflatpak, AppImageなどの新たなパッケージ管理方法がディストリビューションの枠を超えて普及するのではないかと考えます。

最後に

コーヒーブレイク用にお送りしたLinuxのパッケージ管理のお話いかがだったでしょうか？当ブログにいらっしゃるような方には特に目新しい話はなかったとお叱りを受けるかも知れませんね。ディストリビューションやパッケージ管理について、語り合うことができるのもLinuxユーザーの楽しみだと思っています。