ソースコードは公開されておらず無料でもないため、インストール時にコンパイルすることはできません。これまでに次のような開発者を見てきました:
- tar.gz ファイルが提供され、適切な場所で解凍するのはユーザーの責任です。
- 基本的なインストーラーを実行するための install.sh スクリプトを含む .tar.gz を提供し、ユーザーにインストール オプションの入力を求めることもできます。
- RPM および/または deb ファイルを提供し、ユーザーが使い慣れたネイティブ パッケージ管理ツールを引き続き使用してインストール/アップグレード/アンインストールできるようにします。
できるだけ多くの Linux ディストリビューションをサポートし、ユーザーの生活をできるだけ楽にしながら、ビルド/パッケージング/インストーラーのインフラストラクチャをできるだけ少なく維持したいと考えています。
ソフトウェアをパッケージ化する方法に関する推奨事項を探しています。
答え1
私には、それを捉える方法が2つあるように思えます。
1 つは、最も人気のある Linux をターゲットにして、それぞれにネイティブ パッケージを提供し、パッケージを人気順に配信することです。数年前は、まず Red Hat タイプの Linux 用の RPM を提供し、その後、時間の許す限り、あまり人気のない RPM ベースの Linux 用のソース RPM を再構築していました。このため、たとえば Mandriva RPM は Red Hat や SuSE RPM よりも少し古いものになることが多いのです。ただし、ここ数年 Ubuntu が非常に人気になっているため、.deb から始めて、後で RPM を追加したほうがよいかもしれません。
もう一つは、ターゲットを絞ることです全てLinux を一度にすべてアンインストールすることは、バイナリ tarball を提供している人たちが試みていることです。システム管理者としてもエンド ユーザーとしても、私はこのオプションが本当に嫌いです。このような tarball は、解凍したシステム全体にファイルを散らばらせ、後でアンインストール、パッケージの検証、インテリジェントなアップグレードなどの便利なオプションがありません。
混合アプローチを試すこともできます。つまり、最も人気のある Linux 用のネイティブ パッケージと、変わった Linux や、何らかの理由でパッケージ マネージャーを好まない旧式のシステム管理者向けのバイナリ tarball です。
答え2
私は常にパッケージ (rpm|deb など) を好みます。ソフトウェアの性質によっては、特定のディストリビューション (rhel/centos など) 向けのパッケージをターゲットにする価値があるかもしれませんが、おそらくすべての人に十分なパッケージを提供することは不可能でしょう。
インストール スクリプトは、スクリプトによっては問題ありません。私にとって、パッケージ化されていないソフトウェアで最も重要なことは、選択した場所に簡単にインストールできることです。
答え3
ゲームではインストーラー (以前は Loki Installer、現在は MojoSetup) が使用される傾向があり、インストーラーはゲームをプレフィックスにきれいにインストールし、アイコンなどを処理します。