Linuxをサポートするために市販のソフトウェアで使用する必要のあるインストーラーの種類は何ですか？

ソースコードはオープンまたはフリーではないため、インストール時のコンパイルはオプションではありません。これまでのところ、次のような開発者を見てきました。

• tar.gzファイルを提供し、適切な場所で解凍するのはユーザー次第です。
• .tar.gzにinstall.shスクリプトを提供して、基本的なインストーラーを実行します。インストールオプションをユーザーに要求することもできます。
• RPMおよび/またはdebファイルを提供し、ユーザーが使い慣れたネイティブパッケージ管理ツールを引き続き使用して、インストール/アップグレード/アンインストールを行えるようにします。

ほとんどのLinuxディストリビューションをサポートし、ユーザーの生活をできるだけ簡単にし、ビルド/パッケージング/インストーラーインフラストラクチャもできるだけ少なくしたいと考えています。

ソフトウェアのパッケージ方法に関する推奨事項を探しています。

それを見るには2つの方法があります。

1つは、最も人気のあるLinuxをターゲットにして、それぞれにネイティブパッケージを提供し、パッケージを人気の高い順に配信することです。数年前、それは最初にRed HatタイプのLinux用のRPMを提供することを意味し、その後時間が経つにつれて人気の低い各RPMベースのLinux用のソースRPMを再構築することを意味しました。これが、Mandriva RPMがRed HatまたはSuSE RPMよりも少し古いことが多い理由です。しかし、ここ数年、Ubuntuが非常に人気を博しているため、.debから始めて、後でRPMを追加することもできます。

もう1つは、すべての Linuxを一度にターゲットにすることです。これは、バイナリtarballを提供するLinuxが試みていることです。sysadminとエンドユーザーとして、私はこのオプションが本当に嫌いです。このようなtarballは、ファイルを解凍したシステム全体にファイルを分散します。アンインストール、パッケージの検証、インテリジェントなアップグレードなどの便利なオプションはありません。

混合アプローチを試すことができます。最も人気のあるLinux向けのネイティブパッケージ、さらに、奇妙なLinux向けのバイナリtarballと、何らかの理由でパッケージマネージャーを好まない旧式のシステム管理者です。

何をする場合でも、エラーのトラブルシューティングのためにターゲットシステムでできるだけ多くの情報を収集できるようにする「サポートスクリプト」を必ず含めてください。問題が発生し、顧客が言うことと現実とのデバッグはしばしば非常に異なることを保証します。

私の好みは常にパッケージ（rpm | debなど）です。ソフトウェアの性質によっては、特定のディストリビューション（rhel / centosなど）のパッケージを対象とする価値があるかもしれませんが、すべての人に十分なパッケージを提供することはできないでしょう。

スクリプトによっては、インストールスクリプトに問題はありません。私にとって、パッケージ化されていないソフトウェアで最も重要なことは、選択した場所に簡単にインストールできることです。

ゲームはインストーラー（以前のLoki Installer、現在はMojoSetup）を使用する傾向があり、ゲームをプレフィックスにきれいにインストールし、アイコンなどを処理します。