オープンソースの貢献者である Hari Rana 氏は、伝統的な Linux パッケージ形式はもはや最新のアプリケーションには適さないという見解を示しています。
LTS や安定版 (Stable)のアプリケーションパッケージの問題について文句を言うユーザを何度も見かけました。しかし、パッケージ技術に関する私の経験と知識では、これは真実ではないことをいくら強調しても足りません。
根本的な問題は、従来のパッケージフォーマットが、ディストリビューションに関係なく、最新のグラフィックスアプリケーションに適していないということです。では、NixやFlatpakのようなフォーマットは、このような根本的な問題をどのように解決するのでしょうか？興味深いことに、ほとんどのサーバはコンテナ化を利用しています。ここからヒントを得て、Linuxデスクトップに同様の標準を採用することもできるでしょう。
責任を否定または制限する声明
- レガシーパッケージ」とは、apt、dnf、pacman などのコンテナを使わずにパッケージマネージャを使って配布されるグラフィカルアプリケーションのことです。
- 「リリースモデル」とは、長期サポート版、安定版、開発版などのリリースプロセスを指します。
- 類似アプリケーション」とは、 Visual Studio Code Code - OSSように、技術的に本当に類似している2つのアプリケーションのことです。
- Nixはコンテナを使いませんし、コンテナ・フォーマットでもありません。しかし、簡単のために、今はコンテナ・フォーマットと呼ぶことにします。
基本的な問題
伝統的なパッケージ形式を多用しているほとんどのディストリビューションには、この共通の問題があります。平たく言えば、コンテナとは、メインシステムに影響を与えることなく、物を入れて個別に使うことができる箱のことです。
コンテナは通常、「箱」の外では何も影響を与えません。また、一貫したエクスペリエンスを提供しながら他のディストリビューションにインストールできるため、移植性があります。コンテナを利用するパッケージマネージャは、各パッケージを異なるコンテナにインストールします。これにより、開発者はより多くのコントロールと柔軟性を得ることができ、パッケージ内に何をバンドルするかを決めることができます。
従来のパッケージ形式は、依存関係やパッケージの衝突といった問題を引き起こし、しばしば解決する必要があります。
依存関係とパッケージの競合
この問題は Visual Studio Codeと Code - OSS Arch Linux にインストールされている場合に発生します：
$ paru -S visual-studio-code-bin:: Conflicts found:visual-studio-code-bin: code:: Conflicting packages will have to be confirmed manuallyAur (1) Old Version New Version Make Onlyaur/visual-studio-code-bin 1. No
これはパッケージの競合として知られており、2つ以上のパッケージが共存できません。この場合、Visual Studio Code と Code - OSS は同時にインストールできません。
2つのアプリケーションやソフトウェアパッケージが同じファイルを提供し、同じ名前を持ち、同じディレクトリに配置されている場合、ファイルが衝突するため、実際には共存できません。この例では、Visual Studio CodeとCode - OSSの両方がcodeというファイルを提供し、/usr/binに配置されています。Visual Studio Codeが提供するcodeファイルはVisual Studio Codeの起動に使用され、Code - OSSが提供するcodeファイルはVisual Studio Codeの起動に使用されます。この例ではVisual Studio CodeとCode - OSSのみを示していますが、異なるアプリケーション、ライブラリ、その他のソフトウェアではこのようなことがよく起こります。
依存関係を選択できません
従来のパッケージ形式の最大の問題の一つは、パッケージャが依存関係を選択できないことです。
例えば、あるアプリケーションが最近更新され、バージョン 1 のプログラム A に依存する必要があるにもかかわらず、ディストリビューションがバージョン 0.9 のプログラム A しか提供していない場合、ディストリビューションがその要求を満たすことができないため、アプリケーションをアップグレードするには理想的ではありません。これは、ディストリビューションがその要件を満たすことができないため、アプリケーションのアップグレードには理想的ではありません。つまり、パッケージャは、ディストリビューションが新しい依存関係をリリースするまで保留するか、回避策を使わなければなりません。
同様に、あるアプリケーションがプログラムAのバージョン0.8.1に依存しているにもかかわらず、ディストリビューションがプログラムAのバージョン0.9しか提供していない場合、そのアプリケーションは動作不良を起こすか、あるいはまったく実行できなくなります。
パッチとコンパイル設定を含むライブラリ
拡張性を高めるために、アプリケーションの中にはパッチを当てたライブラリや追加のコンパイル設定を必要とするものがあります。例えば、OBS Studioは パッチを当てたFFmpeg することでOBS Studioとの統合を向上させることができます。
従来のパッケージ形式では、一度にインストールできる依存関係は 1 種類だけです。ディストリビューションがパッチの適用されていない FFmpeg を提供する場合、パッケ ージ作成者がこれを回避しない限り、パッチの適用された FFmpeg をインストールする 方法はありません。パッチが適用されたFFmpegがインストールされたとしても、他のアプリケーションがパッチの適用されていないFFmpeg、他のパッチが適用されたFFmpeg、他の機能が組み込まれたり削除されたりしているFFmpegに強く依存している場合、他のアプリケーションにバグが発生します。
最近のアプリケーションは本質的に脆弱です。依存関係ツリーにおける小さなエラーや不整合は、アプリケーションのバグにつながり、ユーザエクスペリエンスを悪化させ、パッケージそのものではなく、アプリケーションに問題があると思わせることで、アプリケーションの評判を落とすことさえあります。
回避策
開発者がアプリケーションをパッケージ化するために現在使っている回避策を見てみましょう：
- 最初の解決策は、依存するライブラリを異なるディレクトリにインストールすることです。例えば、Electronは開発者がアプリケーションをビルドし、それらをバンドルするために使用する巨大なフレームワークです。Arch Linux の Electron パッケージングでは、いくつかのディレクトリを
/opt/APPLICATION_NAMEにインストールする必要があります。Arch Linux の Electron パッケージングでは、いくつかのディレクトリは _ にインストールする必要があるので、これらの Electron のバージョンは 競合しないしません。 - 二つ目の解決策は、アプリケーションを改ざんすることです。例えば、特定の依存ライブラリや機能なしにコンパイルするようにアプリケーションにパッチを当てることで、アプリケーショ ンは正常にコンパイルできるかもしれませんが、アプリケーションが期待通りに起動したり動作したりする保証はありません。
- 3つ目の解決策は、アプリケーションのコンパイル時に多くのコンパイルオプションを無効にすることです。例えば、Arch Linux では、OBS Studio はコンパイル時に多くの基本機能を無効にします。
これらの解決策は人によって異なり、アプリケーションの機能を制限するものや、安定性の問題を引き起こすものなどがあります。
一貫性のない経験
このような技術的な制限は従来のパッケージ形式では一貫していますが、ユーザエクスペリエンスはそうでないことがよくあります。パッケージの配布方法によって、配布モデルと従来のパッケージフォーマットが組み合わさることで、ユーザーエクスペリエンスに影響を与える可能性があります。
Arch Linux のようないくつかのディストリビューションは開発版に近いため、最新バージョンのパッケージを持っています。しかし、Debian と Ubuntu LTS は LTS 長期サポートリリースなので、パッケージの多くは数バージョン遅れています。一方、Fedora Linux と Ubuntu Stable は Debian / Ubuntu LTS と Arch Linux の中間です。
このように、アプリケーションはディストリビューションによって大きく異なって構築されます。加えて、依存関係もディストリビューションによって異なります。伝統的なパッケージフォーマットの技術的な制限の多くは、ディストリビューションモデルとパッケージ戦略によって異なる解決策を必要とします。このような些細な違いは、しばしばユーザに不完全で標準以下の体験や誤った印象を与えます。あるアプリケーションは、あるディストリビューションではよく動くかもしれませんが、他のディストリビューションではうまく動かないかもしれません。アプリケーションがそれぞれのディストリビューションで異なるようにビルドされていても、その名前とブランディングは同じままであり、ユーザに間違った印象を与えます。
ソリューション
前述のように、これらの問題を解決するのがコンテナの使用です。
コンテナは、システムのいくつかの側面を分離するために設計されています。コンテナを使用することで、パッケージ作成者はホスト上のライブラリに制限されることなく依存関係を選択することができます。その結果、パッケージ作成者はディストリビューションの安定性を維持しながら、最新で完全に機能するパッケージをリリースすることができます。
なぜなら、これらのコンテナ形式は、システムを混乱させることなく、アプリケーションやディストリビューションの長所を引き出すことができるからです。
ニックスとフラットパック
Nixは 、Linuxディストリビューション、BSD、macOSなどのUnixライクなオペレーティングシステム上で動作するクロスプラットフォームパッケージマネージャです。 Nixには、ユーザが利用できるいくつかの チャンネルがあります。
一方、Nix Linuxデスクトップ向けの汎用パッケージフォーマットで、コンテナも利用しますが、さらにコンテナをサンドボックス化して隔離します。Flatpakは後に一般公開される予定で、ソフトウェアショップとの統合を想定しています。言い換えれば、Flatpakは元々システムパッケージマネージャを置き換えるために設計されたものではないため、パッケージフォーマットの置き換えというよりは、ディストリビューションの拡張機能です。
Nixは拡張としても使えますし、NixOSなどのディストリビューションを使えばそれ自体で使うこともできます。
類似アプリケーション
NixとFlatpakは、従来のパッケージフォーマットの基本的な問題の多くを解決します。アプリケーションの分離により、これらのフォーマットは、Visual Studio CodeとCode - OSSのような類似のアプリケーションを競合することなくインストールすることができます。
マルチバージョン
NixとFlatpakは同じアプリケーションの複数のバージョンをインストールできます。Nixを使えば、あるアプリケーションをnixpkgs-stableからインストールし、同じアプリケーションをnixpkgs-unstableからもインストールできます。
同様に、Flatpakを使えば、安定版ブランチとベータ版ブランチの両方からアプリケーションをインストールできます。コンフリクトに遭遇することなく、より多くのルートやブランチから同じアプリケーションをインストールし続けることができます。
うるさい依存関係
さらに、パッケージャは、アプリケーションをさまざまな種類のライブラリとバンドルすることができ、より多くのビルドオプションを有効にしたり、パッチが適用されたライブラリや特定のバージョンのライブラリを使用したりして、ユーザーに完全なエクスペリエンスを提供する機会を得ることができます。
つまり、パッチを適用したFFmpegをOBS Studioにバンドルすることができます。ホストマシンに通常のFFmpegがインストールされていれば、OBS Studioのパッチ付きFFmpegがホストマシンのFFmpegと干渉したり競合したりすることはありません。
環境はディストリビューション間で一貫しています。
上述したように、ディストリビューションは異なるパッチ、ビルドオプション、環境を使用してアプリケーションをビルドします。これはアプリケーションの断片化につながり、それぞれのアプリケーションはしばしば異なるビルドと動作をします。NixとFlatpakはディストリビューション間で動作するように設計されているので、ディストリビューションがNixやFlatpakのサポートバージョンを提供していれば、各ディストリビューションのアプリケーションに一貫した環境を提供します。
デメリット
あらゆるものがそうであるように、NixとFlatpakは完璧ではありません。最近、Linuxデスクトップでコンテナ技術を推進する動きがあるため、これらは多くのアプリケーションに通常とは異なる環境を提供するかもしれません。
Flatpakの開発者は、静的パーミッションとして知られる「サンドボックスに穴を開ける」という短期的な回避策を実装しています。彼らは、サンドボックスに関する多くの問題に対処し、Android のセキュリティ モデルのようにするために、 チャンネル呼ばれる適切な長期的ソリューションに取り組んでいます。
唯一の短期的な問題は、ツールキットやフレームワーク、アプリケーションがこれらの標準を採用しなければならないことです。GTKやQtのようなツールキットはこれらの一部を統合していますが、他のポータルも統合するには時間がかかります。その一方で、他の多くのツールキットはまだどのポータルも統合していません。
XDGポータルには適切な標準がないため、ツールキット、フレームワーク、アプリケーションによるこれらの新しい標準の採用は時間の問題です。アプリケーションはファイルシステムやAPIに直接アクセスできるため、静的パーミッションがこの「標準」を維持します。
はんけつをくだす
従来のパッケージ形式の根本的な問題は、コンテナを利用しないことです。多くのグラフィカル・アプリケーションは本質的に複雑で、期待通りに動作するためには非常に特殊な依存関係を必要とします。多くのディストリビューションは、アプリケーションにパッチを当てたり、特定のビルドオプションを無効にするなどの回避策を使って、異なる環境で同じアプリケーションをビルドします。その結果、アプリケーションのバリエーションが異なり、動作が一貫せず、標準以下のユーザーエクスペリエンスになります。
もちろん、ディストリビューションのメンテナが数日でパッケージマネージャを書き換え、コンテナを使用することは現実的に不可能です。そのような書き換えは多くのスクリプトや機能などを壊してしまうでしょうし、本番環境に導入するには長い時間がかかるでしょう。
Flatpakは既存のディストリビューションを拡張するものであり、置き換えるものではないからです。なぜなら、Flatpakは既存のディストリビューションを拡張するものであって、置き換えるものではないからです。パッケージャは、アプリケーションのパッケージングや回避策について心配する必要はありません。
Hariは、Fedora MagazineのFedora Editorial Boardのメンバーであり、Fedoea Quality Assuranceのメンバーでもあります。また、Fedoea Quality Assuranceのメンバーでもあります。Hariは、様々なテクノロジーを普及させ、それを必要とする人々を支援することで、Linuxデスクトップの普及に貢献したいと考えています。
本記事で述べられている見解および意見は、筆者のものであり、意見を代表するものではありません。
