AMはAppImageをLinuxの運用単位に変えるか

AppImageを置き場所まで管理する設計

AMはAppImageとその他のポータブル形式を、インストール、更新、削除、メニュー登録まで扱うBASHスクリプトとモジュールの集合です。READMEはAPTがDEBを扱う関係になぞらえ、Arch User Repositoryに影響を受けたアプリ別のShellスクリプトデータベースを中核に据えると説明しています。対象アプリの一覧はportable-linux-apps.github.io/appsで公開されています。

ここでの価値は、単にファイルをダウンロードすることではありません。アプリごとに配置、バージョン情報、更新用スクリプト、削除用スクリプトをそろえることで、AppImageを手作業で置いたままにしない流れを作ります。一方、上流のアプリそのものを修正する仕組みではないため、対象アプリの品質をAMの機能と読み替えることはできません。

AMとAppManを権限の境界で選ぶ

READMEにはAM-INSTALLER、Gitによる導入、wgetまたはcurlを使うワンライナーが記載されています。システム全体のAMはroot権限を使い、標準配置では/opt/amに本体とmodules、/usr/local/bin/amに呼び出し口を置きます。導入前にsudoまたはdoasが使える環境かを確認する必要があります。

AppManはローカル利用を目的とした形態で、ユーザー領域にアプリを置けます。AM自体も--userを付ければ同じ方向で動作し、READMEはAMのバージョン9以降でモードを切り替えずローカルアプリを管理できると説明しています。共有端末ではシステム導入の影響範囲を、個人環境では設定保存先とバックアップ対象を分けて考えるのが実務的です。

インストール処理が作るファイル群

アプリの導入は、基本ディレクトリと削除スクリプトの作成、パッケージの取得、バージョンファイルと更新スクリプトの作成、存在する場合のアイコンと.desktopファイルの抽出という順序で説明されています。システム全体では/opt/$PROGRAMにアプリを置き、/usr/local/binへシンボリックリンクを作り、/usr/local/share/applicationsへデスクトップエントリーを配置します。

ローカル導入ではユーザーが指定したディレクトリが使われ、初回のam -i --userまたはappman実行時に設定されます。設定は~/.config/appmanに保存されるため、移行や削除の前にこの位置を確認できます。アプリごとに生成物が異なる可能性はREADMEから断定できないので、実際のインストール後にリンク、アイコン、更新ファイルの存在を確認するのがよいでしょう。

検索用データベースと外部カタログ

am -lは利用可能なアプリの一覧、am -qはキーワード検索、am -iは導入に使います。データベースはアーキテクチャごとのインストールスクリプトで構成され、対象が登録済みかを調べてからコマンドを実行できます。未登録のAppImageを統合する案内もREADMEにあり、登録状況だけでポータブルアプリ全体を網羅すると理解するのは適切ではありません。

サードパーティーデータベースには専用フラグを付けてアクセスします。APPSDB、APPSDBLIST、APPIMAGES_LIST、AMCATALOGUEMARKDOWNS、AMCATALOGUEICONSなどの変数をエクスポートし、既定データベースを置き換える手順も示されています。外部カタログを使う場合は、スクリプトの取得元と更新頻度を組織側で記録してください。

形式依存の補助コマンドを先に洗い出す

必須のコア依存関係としてcoreutils、curl、grep、sedが挙げられています。curlがないとオンラインのリストやURL、バージョン情報を読めず、検索や取得の入口で止まります。root権限の要否もAMとAppManで異なるため、導入方法と依存関係を同時に確認する必要があります。

7z、ar、tar、unzip、xz系、wget、checksum用コマンドなどは、対象パッケージの形式や作業によって必要になる任意依存です。READMEはappimageupdatetoolを差分更新、appimagetoolを古い形式の変換や構築、aisapまたはsasをサンドボックス用途の補助ツールとして案内しています。扱うアプリの形式を決めてから不足コマンドを追加する方が、不要な依存を増やさずに済みます。

更新と隔離を同じ運用表に置く

am -uはインストール済みアプリとAM自身を更新し、--appsを付ければアプリだけに絞れます。特定のプログラムを指定した更新や、--debugによる出力確認もREADMEに記載されています。更新元が各アプリのスクリプトに依存する構造なので、更新後はバージョンファイルと実体の対応を確認し、問題が起きた対象だけを切り分ける必要があります。

--sandboxはaisapまたはsasと連携し、-iasなら導入とサンドボックス化を一度に指定できます。これはアプリの動作範囲を制限する選択肢ですが、全アプリで同じ結果になるとはREADMEから判断できません。実際に起動、ファイルアクセス、メニュー登録を試し、アプリ側の不具合はam -aやam -dで得た情報を使って上流へ報告する、という責任分担を明確にすべきです。

編集部の結論

AppImageを配布形式として選び、端末から複数アプリを管理したいLinux利用者には候補になります。システム全体に置くかユーザー領域だけに置くかを先に決め、coreutils、curl、grep、sedとsudoまたはdoasの有無を確認してください。導入後は対象アプリのスクリプト、更新元、デスクトップ登録先を実機で照合し、個々のアプリの不具合までAMの責任と誤解しない運用が必要です。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes