Linuxをサポートするために商用ソフトウェアはどのインストーラータイプを使用する必要がありますか？
ソースコードが開いていないか無料ではないため、インストール時にコンパイルすることはできません。これまでのところ、私は次のような開発者を見てきました。
- tar.gzファイルを提供し、適切な場所で解凍するのはユーザーの責任です。
- .tar.gzにinstall.shスクリプトを提供して、基本的なインストーラーを実行し、場合によってはユーザーにインストールオプションの入力を求めることもできます。
- rPMおよび/またはdebファイルを提供し、ユーザーが使い慣れたネイティブパッケージ管理ツールを引き続き使用してインストール/アップグレード/アンインストールできるようにします。
最も多くのLinuxディストリビューションをサポートし、ユーザーの生活を可能な限り簡単にし、ビルド/パッケージング/インストーラーインフラストラクチャも可能な限り少なく維持したいと考えています。
ソフトウェアをパッケージ化する方法に関する推奨事項を探しています。
私はそれを見る2つの方法を見ます。
1つは、最も人気のあるLinuxをターゲットにして、それぞれにネイティブパッケージを提供し、人気のある順序でパッケージを配信することです。数年前は、最初にRed HatタイプのLinuxにRPMを提供し、その後、時間の許す限り、人気の低いRPMベースのLinuxごとにソースRPMを再構築することを意味していました。これが、たとえば、MandrivaRPMがRedHatまたはSuSERPMよりも少し古いことが多い理由です。ただし、ここ数年はUbuntuが非常に人気があるため、.debから始めて、後でRPMを追加することをお勧めします。
もう1つは、一度にall Linuxをターゲットにしようとすることです。これは、バイナリtarballを提供するものが試みていることです。私は、システム管理者およびエンドユーザーとして、このオプションが本当に嫌いです。このようなtarballは、ファイルを解凍したシステム全体にファイルを分散させます。後で、アンインストール、パッケージ検証、インテリジェントアップグレードなどの便利なオプションはありません。
さまざまなアプローチを試すことができます。最も人気のあるLinux用のネイティブパッケージに加えて、なんらかの理由でパッケージマネージャーが好きではない奇妙なLinuxや古い学校のシステム管理者用のバイナリtarballです。
何をするにしても、エラーのトラブルシューティングのために、ターゲットシステムで可能な限り多くの情報を収集できる「サポートスクリプト」を含めるようにしてください。私はあなたが問題に遭遇し、顧客が言うことと現実をデバッグすることはしばしば非常に異なることを保証します。
私の好みは常にパッケージ（rpm | debなど）です。ソフトウェアの性質によっては、特定のディストリビューション（rhel/centosなど）のパッケージをターゲットにする価値があるかもしれませんが、おそらくすべての人に十分なパッケージをロールすることはできません。
スクリプトによっては、インストールスクリプトで問題がない場合があります。私にとって、パッケージ化されていないソフトウェアで最も重要なことは、選択した場所に簡単にインストールできることです。
ゲームはインストーラー（以前のLokiインストーラー、現在はMojoSetup）を使用する傾向があります。インストーラーは、ゲームをプレフィックスにクリーンにインストールし、アイコンなどを処理します。