執筆時点のFlatpakバージョン：1.14.4
「Flatpak、Linuxアプリケーションの未来」Flatpak公式サイトにはそう書かれている。
なぜLinuxでアプリケーションをインストールすることが、時に大きな悪夢になるのか？なぜFlatpakはこの問題を有効に緩和できるのか？
この記事ではIvonが、なぜFlatpakが生まれたのか、そしてFlatpak技術の長所と短所を簡単に紹介する。
用語解説：
- 「システムプログラム」とは、コンパイラ、runtime、ライブラリなどのソフトウェアを指す。
- 「グラフィカルプログラム」とは、グラフィカルインターフェースを持つ文書ソフト、画像処理、ブラウザなどのソフトウェアを指す。
＊ 本稿でIvonが主に議論するのはFlatpak技術の長所と短所であり、Flatpakパッケージとコマンドの実際の使い方についてはこの記事を参照してほしい。
1. Linuxディストリビューションのアプリケーションインストール問題#
まずFlatpakが生まれた背景から話そう。
Linuxでアプリケーションをインストールするには、パッケージマネージャー(package manager)を通じてダウンロード・インストールすればよい、ということは皆知っている。アプリストアの背後でやっていることも基本的にはそれである。
Linuxには現在、少なくとも100以上のディストリビューション(distribution)があり、これがソフトウェアのパッケージング問題を生んでいる。
異なるディストリビューションにはそれぞれ各種パッケージマネージャーがあり、アプリケーションをインストールするコマンドも違う。時にはパッケージ依存関係(dependencies)の衝突も発生する。
さらに、各ディストリビューションは自分たちのオンラインパッケージリポジトリ(repository)を維持する。人気のディストリビューションは多くのプログラムを収録しており、たとえばUbuntuやArch Linux AURはほぼ何でもある。それに比べ、マイナーなディストリビューション（Void、Alpine）はコミュニティが形成されてからでないとリポジトリの量が蓄積されず、そうでなければ手動でソースコードからコンパイルするしかない。
異なるディストリビューションでパッケージングすると、アプリケーションのバージョンが一致しなくなる。新しいUbuntuは最新のプログラムを収録するが、LTS版では少し遅れる、といったように更新が同期しない。
だからディストリビューション横断でアプリケーションをインストールする技術を統一しようとするものが登場した。Flatpakはその例の一つであり、他にはSnapとAppImageがある。
2. Flatpakとは何か#
Flatpakは、以前はxdg-appと呼ばれていた、RedHatが始めたディストリビューション横断パッケージマネージャーおよびパッケージデプロイシステムである。大部分のLinuxディストリビューション（Debian系、Fedora系、openSUSE系、Arch系）はすでにFlatpakをサポートしており、ChromeOSにまであり、Fedora Silverblueに至ってはほぼ全Flatpak環境である。
Flathubは最も人気のあるFlatpakリポジトリで、すでに数千のアプリケーションが掲載されている。
近年、Linuxの グラフィカル アプリケーションは、徐々に統一配布の傾向へ向かっている。Snap、Flatpak、AppImageのようなディストリビューション横断技術に依存し、各ディストリビューションのパッケージマネージャーが自分でパッケージングすることには依存しないことで、プログラムのバージョン不一致問題を防ぐ。
Flatpakが主に狙う対象はデスクトップのグラフィカルアプリケーションであり、たとえばブラウザ、文書処理、画像処理、ゲームなどだ。FlatpakはAPPを隔離するsandbox機構を導入し、安全性を強化するための権限システムも設計している。
3. Flatpakでアプリケーションをインストールする長所#
3.1. Flathubは開発者のデプロイと公開に便利#
Flathubは開発者にとって利点がある。Flatpak公式ドキュメントには、アプリケーションをFlatpakへパッケージングする方法が詳しく説明されており、開発者にXDG標準を守るよう促している。開発者はアプリケーションを配布するとき、安定版とテスト版をユーザーへ提供でき、x86 / ARMなど異なるアーキテクチャのバージョンも提供できる。Flatpakのインストーラーが自動で判断してくれる。
通常ユーザーはFlathubリポジトリからFlatpakパッケージをダウンロードする。一部の組織は自前でFlatpakリポジトリを運営しており、たとえばRedhHatがある。FlathubはCanonicalのSnap Storeとは少し違う。それは一私企業のプラットフォームではなく、GNOME基金会が運営するサイトであり（出典）、アプリケーションの提出に費用は不要で、Githubで自由にFlatpakパッケージを提出できる。ユーザーもFlatpakのリモートリポジトリを自由に切り替えられ、Flathub単一プラットフォームに合わせてアプリケーションをダウンロードする必要はない。
Flathubサイトはアプリケーションのダウンロード数、AppStreamのユーザー評価、ソフトウェアライセンス条項、権限などの情報を表示する。アプリケーションのダウンロードページには大きな「寄付」ボタンが表示されるほか、将来は有料チャネルを導入する可能性もある。
エンドユーザーにとって、Flatpakは各ディストリビューションでアプリケーションのバージョンが不一致になる問題を解決した。あなたがローリングリリースのArch Linuxを使っていようと、万年に一度しか更新しないDebianを使っていようと、Flatpakを通じてバージョンが一致したアプリケーションを享受できる。さらにFlatpakは、アプリケーションをシステムへインストールするか、特定ユーザーだけにインストールするかを選べる。これにより一般ユーザーはrootパスワードなしでプログラムをインストール、削除できる。
3.2. Runtimeとシステムの隔離#
Flatpakは可能な限り既存のruntimeを再利用し、容量使用を減らす。だからFlatpakアプリケーションを多く入れるほど、容量使用は問題ではなくなる。開発者の説明によれば、Flatpakを多く入れるほど、容量利用はより効率的(efficient)になる。
Flatpakがruntimeを一緒に包むことには利点がある。各アプリケーションが同じruntimeを使うことを保証でき、ディストリビューションのシステムパッケージに依存せず、ディストリビューションがruntimeへpatchを当てた結果、奇妙なbugが出るのを防げる。さらにFlatpakの旧版runtimeはEOL後も同じように提供され、依存性地獄の問題を緩和する。
たとえば、あるアプリケーションが特定バージョンのPythonに依存する場合、システムパッケージマネージャーでインストールするとPythonをグローバルにインストールする必要があり、システム更新で壊れるかもしれない。Flatpakでインストールすれば、Pythonは自動でアプリケーションと一緒に包まれ、システムのPythonパッケージとは分離される。
Flatpakはglibcに依存するアプリケーションをmusl libcのLinuxディストリビューション上で実行させることさえできる。これがシステムパッケージに依存しない利点だ。
FlatpakはSnapと同じくパッケージ管理機能を持ち、アプリケーションストア（KDE Discover、GNOME Software）と統合して、グラフィカルインターフェースで管理できる。一方AppImageは相対的に管理しにくく、AppImage Launcherを使わない場合、ユーザーは実行ファイルの保存位置を覚えなければならない。またAppImageはより大きな程度でシステム下層のruntimeへ依存するため、本当にすべてのディストリビューションで使えるわけではない。musl libcのシステムでは多くのAppImageが開けず、再コンパイルが必要になる。Flatpakはruntimeを一緒に包む方法でこの問題を解決した。
3.3. sandboxで安全性を高める#
下図はFlatpak公式ドキュメントが説明するsandboxの動作原理である。Flatpakアプリケーションの依存パッケージとruntimeはFlatpakが管理し、アプリケーションのインストール時に自動でダウンロードされる。
安全性の角度から見ると、Flatpakが導入した権限機構はAndroidと似ているところがある。Googleは近年、Android APPが一部の常用ディレクトリにしかアクセスできないよう規定し、システムの安全と整然さを保証している。Flatpakでインストールしたアプリケーションにもこの類の効果があり、アプリケーションがホームディレクトリへ設定ファイルを乱雑に詰め込むことを防ぐ。Flatpakはアプリケーションによるネットワークサービスや特定ハードウェア機器へのアクセスを制限できる。
理想的には、開発者はFlatpakプログラムとしてパッケージングするとき、Flatpakが提供するPortal API一式を活用してユーザーファイルへアクセスすべきである。
一部Linuxのアプリケーションストアは、インストールページにそのFlatpak APPが使う権限を列挙する。図はKDE Discoverが列挙するFirefoxの権限である。
FlatsealはFlatpakプログラムの権限編集に使え、コマンドを打つ必要がない。
最後に、Flatpakでインストールしたプログラムデータは統一して~/var/appに置かれる。これによりFlatpak経由でプログラムをアンインストールするとき、関連するアプリケーションデータをワンクリックで削除できる。
私たちはFlatsealのようなプログラムを通じてアプリケーションの権限をオン・オフでき、必要なときにはアプリケーションにユーザーの全ファイルへのアクセスを許可できる。
4. Flatpakでアプリケーションをインストールする短所#
4.1. アプリケーションが肥大化する#
Flatpakアプリケーションは重い。特にFlatpakでアプリケーションをあまりインストールしない場合はそうだ。Flatpakをインストールすることは、第二のパッケージマネージャーを入れることに等しいため、依存パッケージを別途ダウンロードしなければならない。
例を挙げると、新規インストールしたLinuxシステムでFlatpakを使ってFirefoxブラウザをダウンロードすると、Nvidia、GNOMEなどの依存をインストールするため、さらに500MBの容量が必要になる。しかしシステム本体のパッケージマネージャー経由なら、200MBにも満たないかもしれない。
Flatpakを多用してアプリケーションをインストールすれば、この問題はそれほど深刻ではなくなる。Flatpakソフトウェア同士には共有されるruntimeが一部あり、プログラムを一つ入れるたびに大量の依存を全部再インストールする必要はない。Flatpakの毎日自動更新を設定するのも一つの解決策で、長い間放置した更新で大量の依存をダウンロードする事態を避けられる。さらにFlatpakは増分更新をサポートしている。
4.2. sandbox権限設計が不適切#
Flathubのプログラムはすべてが原作者によって掲載されたものではない。非公式パッケージングのものもあり、そのため一部アプリケーションのバージョンが古かったり、奇妙なbugがあったりする。
一部のFlatpakプログラムはパッケージング後のsandbox権限設計が不適切で、ファイルへ正常にアクセスできない、システム実行ファイルが見つからない、Fcitx5入力メソッドを呼び出せない、デスクトップテーマと統合できないなどの問題を引き起こす。
設定ファイルを乱雑に置く問題もある。一部のFlatpakプログラムは、さまざまな要因により、なおデータを~/.var/app以外の場所へ置き、XDG規範に従わない。
現在Flatpakの権限調整方式は、ユーザーをとても困惑させやすい。誰がこれらのbusが何をしているのか知りたいんだ？バスに乗るのってそんなに難しいのか？
開発者がFlatpak版のプログラムへ少し気を配るなら、Androidのように「権限リクエスト」ダイアログを追加し、ユーザーが権限の用途をより理解できるようにすべきだ。
安全性という点では、Flatpakは実は最も安全な解決策ではない。Flatpakのsandboxはシステムと完全に隔離されているわけではない。Flatpakの権限制限を考えると、Firefox、GIMPのようなプログラムはユーザーのホームディレクトリ内の全ファイルへのアクセスを要求せざるを得ない。そうしなければfile pickerがそもそもファイルを選択できないからだ。さらにVisual Studio Code、QT Creatorは必ずシステム実行ファイルへアクセスする必要がある。そうでなければプログラムをコンパイルできない。
より安全なsandbox実行環境が必要なら、Docker、chroot、仮想マシンの方案のほうがよい選択かもしれない。
しかし安全機構は、ないよりはあるほうがよい。少なくともFlatpakプログラムは互いのデータディレクトリを見ることができない。
もし将来、プログラム開発者がFlatpakのPortal APIを優先的な開発考慮に置いてくれるなら、安全性はさらに強化できる。
4.3. システム統合の問題#
一部のFlatpakプログラムはデスクトップ環境のテーマに従わず、QTプログラムがGNOMEで見ると奇妙に見える。逆にGTKプログラムがKDEで見える場合も同じだ。ユーザーはテーマを適用するために手動で環境変数を設定しなければならず、とても面倒である。
Flatpakでプログラムを実行するコマンドは非常に長くなる。以前は端末でfirefoxと打てば開いたが、Flatpakではflatpak run org.mozilla.firefoxと打たなければならない。
さらにFlatpakはプログラムを環境変数(PATH)へ追加しない。そのため一般パッケージマネージャーの方式でfirefoxコマンドを実行しても、システムはFlatpak版Firefoxを見つけられない。別途/var/lib/flatpak/exports/binをPATHへ追加し、aliasを設定して初めて一時的に解決できる。
最後はシステムプログラムとサーバーアプリケーションだ。上で述べたように、Flatpakが主に狙うのはグラフィカルアプリケーションであり、システムプログラム方面のものは比較的少ない。Fcitx5入力メソッドやffmpegはあるが、現在のところFlatpakでJavaやPHPを入れている人は聞いたことがない。これによりサーバー方面ではFlatpakにあまり優位性がなく、比較するとCanonicalが強く推すSnapのほうがより整っている。
Flatpakはいくつかのコンテナ化技術を使っているが、結局DockerやPodmanではないため、headlessのサーバーサービスを動かすには適していない。
Flatpakの困境は、その設計自体がシステム設定を変更できないことにある。はっきり言えば、sudo権限でシステムファイルを動かせないということだ。sandboxを抜けてホストマシンでflatpak-spawnコマンドを実行してできることにも限界がある。これにより、一部ソフトウェアは技術的にFlatpak版を持つことが不可能になる。たとえばリモートデスクトップサーバーや仮想マシンソフトウェアなどだ。
Flatpakでインストールするのに適したアプリケーションは、主にデスクトッププログラムであり、さらにSteamのようにシステム設定を変更する必要がないアプリケーションである。
5. まとめ#
Flatpakが開発者にもたらす利点は明らかで、ユーザーにとってもAPPのインストール手順を簡略化する。ただし容量とsandboxの問題は、今後Linuxコミュニティがどのように改善するかを見る必要がある。
アプリケーションストアのフロントエンドとよく統合できれば、ユーザーのプログラムインストール体験を改善できるはずだ。
