8種類のLinux環境で毎回確認する理由

Linuxで「動く」と言うだけでは十分ではありません。

同じUbuntuでも、バージョンによってシステムライブラリとツールキットが異なります。画面を表示する方式はX11とWaylandに分かれ、ハングル入力メソッドにはibusやfcitx5を使います。インストール方式まで加えると、確認すべき組み合わせは急速に増えていきます。

開発者のコンピューター1台で実行できたということは、数多くの組み合わせのうち一つだけを確認したという意味です。

そこで、リポジトリの中に小さなラボを作りました。環境ごとに実際の仮想マシンを立ち上げ、同じ検査を繰り返します。結果は一つの表にまとめます。

表が確認することは単純です。

アプリが起動するか。ハングルを入力できるか。

ユーザーがアプリをインストールして経験する最初の30秒を、私たちが先に経験してみるのです。

一つの環境を一つのファイルにしました

ラボでは、コンテナの代わりにKVM仮想マシンを使います。コンテナでは、実際のデスクトップセッションと入力メソッドデーモンを正しく再現するのが難しいためです。

ディストリビューションのクラウドイメージを取得し、cloud-initで準備します。ディスクは元のイメージ上にオーバーレイとして作成します。問題が発生したら破棄してやり直せます。

一つの環境を一つのファイルで宣言します。ファイルには、ディストリビューション、イメージ、セッション、入力メソッド、インストールするパッケージが記載されています。新しい組み合わせを確認したければ、ファイルを一つ追加するだけで済みます。

入力方式はセッションによって異なります。X11ではxdotool、Waylandではydotoolを使います。Waylandにはウィンドウ一覧がないため、アプリをキオスクコンポジター上で全画面表示します。そうすることで、毎回同じ位置に入力できます。

アプリはホスト上で一度だけビルドします。そのバイナリをすべての仮想マシンにそのままコピーします。

環境ごとにビルドし直すと、異なるコンパイラーとライブラリが結果に混ざります。失敗したときに原因を突き止めるのが難しくなります。何より、ユーザーが受け取るファイルとラボが検査するファイルは同じでなければなりません。

仮想マシンは検査し、ホストは記録します

仮想マシンの中では、三つのことを確認します。

バイナリが実行されるか、ウィンドウが表示されるか、dkssudと入力したときに안녕が現れるかを確認します。

各検査はJSONを1行残します。ホストは結果を集めてファイルに保存し、表を作ります。測定結果はリポジトリに残し、次の検査と比較します。

ハングル入力は、ビルドによって確認方法が異なります。開発用ビルドでは、組み立て中の文字をすぐに確認できます。実際の配布用ビルドには、その機能がありません。代わりにEnterキーを押してファイルを保存した後、ディスクに記録された内容を読み取ります。

この過程で一つ学びました。検査方法を決めるのは、インストール方式ではなくアプリのビルド種別でした。

最初の表が二つのことを教えてくれました

Ubuntu 22.04では、システムのツールキットでビルドしたアプリが開きませんでした。最新のlibadwaitaにしかないシンボルを見つけられなかったためです。

一方で、Waylandとibusの組み合わせでは、ハングルを正常に入力できることも初めて確認しました。

この結果をもとに、すべてのインストール方式に同じツールキットを含めることにしました。現在の8行の表は、その決定が再び崩れていないかを確認するための安全装置です。

実際の環境でしか見えない問題もありました。クラウドイメージには、デスクトップ版Ubuntuとは異なり、GTK4入力モジュールや初期入力モードがありませんでした。プロビジョニングの過程で別途インストールする必要がありました。

ibusモジュールは、ディストリビューションにインストールされたデーモンのバージョンと一致している必要がありました。ディストリビューションごとに入力ツールの使い方も異なりました。検査スクリプトを環境に合わせて分ける必要がありました。

ホストのメモリを節約するため、仮想マシンは2台までしか同時に実行しません。結果を受け取った仮想マシンはすぐに終了します。

どれもコードを読むだけでは見つけにくい問題でした。同じコードでも、環境によって異なる結果になったからです。だから表が必要でした。

表は性能を約束するものではありません

表には、最初の画面が表示されるまでにかかった時間とメモリ使用量も記録されます。しかし、性能指標としては使いません。

仮想マシンはGPUを使わず、ソフトウェアで画面を描画し、起動直後に一度だけ測定します。実行するたびに値が変わる可能性があります。性能基準は、実際のGPUを搭載したホストで3回測定した中央値によって定めます。

この表で見るべきなのは、ミリ秒ではなくチェックマークです。

確認できていない環境は空欄のままにします。FedoraとDebian、実際のGNOMEセッション、ファイル選択などのポータルダイアログは、まだ表にありません。

確認していない欄を「おそらく動くだろう」と埋めることはしません。

ユーザーがどの環境を選ぶかは、私たちには決められません。私たちにできるのは、その環境に先に入り、アプリを起動してみることです。