ディストロ名か glibc かコンパイラか：インストーラーが確認するもの

インストーラーが「unsupported distribution」と表示し、あなたが文字列を一つ書き換えると、一分後にローダーエラーで失敗するまで処理が進みます。この順序こそが認識すべき症状です。最初の失敗は認識チェックで、二度目は互換性の境界です。同じ端末にたまたま現れる、別々の問題なのです。チェックを書き換えても、最初の問題から二番目へ移るだけです。

症状：インストーラーが派生ディストリビューションで止まる

ディストリビューション名を読んで続行を拒むスクリプトは、作者があなたの派生版を試していないと言っています。それは技術的な事実ではなくサポート上の表明であり、パッケージは問題なく動いたはずだという意味で、しばしば誤りです。

厄介なのは、回避策がそのまま計画になるときです。識別ファイルを変えればチェックは通りますが、そのあとパッケージは、実際にインストールされているランタイムに対して読み込まれるか、失敗します。そこで失敗するなら、識別情報をさらに書き換えても無駄です。

ですから有効なのは、インストーラーがどの問いを立てたのかを突き止め、そのうえでその答えが重要だったのかを突き止めることです。これは二つの別々の調査であり、パッケージが動くかを予測するのは二つ目だけです。

人がシステムのバージョンと呼ぶ三つのバージョン

ディストリビューションのリリースは、パッケージ化された環境を指します。C ライブラリのバージョンは、ランタイムの実装とそのリリースを指します。コンパイラのバージョンは、ツールチェーンを指します。会話では三つとも「システムのバージョン」と呼ばれますが、インストーラーの中では互換ではありません。

cat /etc/os-release
ldd --version | head -1
gcc --version | head -1
uname -m

ビルド済みのアプリケーションは、リンク時に存在したランタイムを前提にします。ホストのコンパイラを差し替えても再リンクはされず、新しいツールチェーンもバイナリが要求するローダーシンボルを変えません。アーキテクチャはまた別の話で、64 ビットシステム上の 32 ビットパッケージは、どのバージョン文字列でも説明できない理由で失敗します。

四つの出力はレポートと一緒に保管してください。集めるのに十秒しかかからず、メンテナーがメールで尋ねてくる質問のほとんどに答えてくれます。

チェックではなくエラーを読む

最初の起動エラーが証拠です。共有オブジェクトが見つからない、あるいはローダーが満たせないシンボルバージョンだというメッセージは、ランタイム依存の問題です。ディストリビューション名を繰り返すメッセージは、別の場所での認識チェックにすぎません。

動的リンカーのドキュメントには、ライブラリ検索の仕組みとローダーが探す場所が書かれています。ディストリビューションのラベルを変えても、その検索パスにディレクトリは追加されません。だから二度目の失敗は一度目と無関係に見えるのです。

ダウンロードした実行ファイルに対して ldd を何気ない最初の一手として使わないでください。そのマニュアル自身が、状況によってはプログラムを実行してしまうことがあると警告しており、信頼できないインストーラーを実行することこそ、その警告が対象とする場面です。

文字列を書き換えても助からない理由

オペレーティングシステムの識別情報を偽ると、マシン上のあらゆるプログラムが自分自身をどう見るかが変わります。パッケージマネージャー、サポートツール、その他のアプリケーションが同じファイルを読み、あるインストーラーを満たす値が数か月後に別の何かを混乱させることがあります。

ホストのライブラリを別ディストリビューションのファイルで置き換えるのは、さらに悪い方法です。無関係なソフトウェアを壊すことがあり、パッケージマネージャーからは見えず、誰も書かない保守計画を必要とします。制約の強いインストーラー一つで、そうした変更を正当化することはできません。

そのチェックが本当に認識の不具合なら、メンテナーが確認し、サポートされる修正を説明できます。不具合でなければ、サポートされる道はあなたのプラットフォーム向けのビルドであり、文字列を書き換えたからといってその答えは変わりません。

メンテナーが行動できるレポートを書く

ディストリビューションとリリース、アーキテクチャ、VPN のリリース、拒否された正確な条件、そこまで進んだなら最初のランタイムエラーを記録してください。何かを変更したかどうかも書き添えてください。変更されたシステムからのレポートは別のレポートだからです。

元のインストーラーはそのままにして、回避するのではなくチェックの内容を説明してください。この区別があるからこそ、メンテナーは狭すぎる認識ルールと本当のバイナリ互換性の境界を切り分けられます。両者はまったく別の不具合で、修正もまったく別です。

あなたのプラットフォームはサポート外だという答えが返ってきたなら、それは使える結果です。問題ではなかった識別ファイルにもう一晩費やすのではなく、サポートされているビルドを探すべきだと教えてくれています。