WindowsからLinuxへのアプリケーションの移植が完了しました。
アプリケーションのインストーラーを作成する必要があります。
アプリケーションはオープンソースではありません=>アプリケーションのバイナリ（実行可能ファイル、結合.soファイル、ヘルプファイル、およびイメージ）を配布する必要があります。
私はそれを行うためのいくつかの方法を見つけました：
-RPMおよびDEBパッケージ;
--.shファイルのインストーラー;
-自動パッケージ。
Linuxディストリビューションごとに異なるパッケージを管理したくないので、最初の方法（RPMおよびDEBパッケージ）は好きではありません。
Linux用のバイナリアプリケーションを配布するための最良の方法は何ですか？
商用製品でこれを数回経験したことから、サポートされている各プラットフォームのネイティブ インストーラーを使用することが最善の答えだと思います。それ以外のものはエンドユーザーに不快な体験をもたらします。実際には、サポートしたいすべてのプラットフォームでテストする必要があるため、それぞれのパッケージを維持することはそれほど大きな負担ではありません. 聞いたことのないものも含め、そこにあるすべてのプラットフォームで「正常に動作する」バイナリを作成できるという考えは、実際にはそれほどうまく機能しません。
最初にサポートするプラットフォームを 1 つまたは 2 つ選択し (Red Hat と Ubuntu をお勧めします)、ユーザーの要求に応じて追加のインストール パッケージを作成することをお勧めします。おそらく、そのプラットフォームでのパッケージ化とテストの時間と労力をカバーする適度な料金で、追加のプラットフォームをサポートする意思があることを知らせてください。プラットフォームが大きく異なる場合は、継続的なサポートに対して追加料金が必要になる場合があります。
ああ、このようなシナリオでの仮想マシンの価値はいくら強調してもしすぎることはありません。サポートするプラットフォームごとに VM を構築する必要があり、さまざまな構成を簡単にテストできるように、プラットフォームごとに複数の VM を構築する必要があります。
多くの良い答えがありました (私のものも含まれています:)) here . それはバイナリ互換性に関するものですが（心配する必要があります）。
インストーラーについては、autopackage をお勧めします (これを使用してソフトウェアのいくつかのバージョンを正常にリリースしました)。"installer.sh" 部分は既に実行されています (デスクトップ統合など)。
パッケージ構造の複雑さに応じて、アップグレードのシナリオなどを慎重にテストする必要がありますが、全体的にはかなりきれいです。1.2.6 で依存関係の処理に関するいくつかのバグを修正したので、問題ないはずです。
更新:元の質問が削除されたため、ここに完全な回答を再投稿し、 Listallerにマージされた autopackage へのすべての参照を無視します。関連する部分が残っているかどうかはわかりません。
ディストリビューションで利用できる可能性が高い標準ライブラリ (crypto++、pthread など) については、動的にリンクし、ディストリビューション リポジトリから取得するようにユーザーに指示します。または、可能であれば静的にリンクします。
バージョンを制御する必要がある奇妙なライブラリの場合 (たとえば、Qt4 アプリを敵のノームの領域に展開する場合)、それらを自分でコンパイルし、アプリだけが知っているプライベート スポットにインストールします。
サポートするすべてのディストリビューションのパッケージ システムに干渉しないことが確実でない限り、プライベート ライブラリを標準の場所にインストールしないでください。（そして、彼らもあなたに干渉することはできません）。
LD_LIBRARY_PATH の代わりに rpath を使用し、相互に参照するすべてのバイナリとすべての dll に対して適切に設定します。バイナリの rpath を "$ORIGIN;$ORIGIN/../lib;/opt/my/private/libs" に設定し、リンカーに標準パスの前にそれらの場所を検索させることができます。（オリジンが動作するようにリンカーフラグを設定する必要があると思います）。libs にも rpath を設定してください: たとえば、QtGui には QtCore が必要で、ユーザーがたまたま別のバージョンの標準パッケージをインストールした場合、絶対にそれを取得したくありません (exe -> ../lib/QtGui.so ( 4.4.3) -> /usr/local/lib/QtCore.so (4.4.2) -- 確実に早く死ぬ方法)。
任意の rpath でコンパイルした場合、後で chrpath で変更できるため、後処理またはインストール スクリプトの一部としてインストール場所を微調整できます。
バイナリ互換性を維持します。GLIB_C はユーザーにとってほとんど静的であるため、十分に古いバージョンにリンクする必要があります。2.3は安全な賭けです。APBuild を使用できます。これは、GLIB_C バージョンを強制し、他のバイナリ互換性に関するトリックをほとんど実行しない gcc ラッパーです。したがって、すべてのアプリを非常に古いディストリビューションでコンパイルする必要はありません。
何かに静的にリンクする場合、通常は APBuild で再構築する必要があります。そうしないと、新しい GLIB_C シンボルをドラッグすることになります。プライベートにインストールするすべての .so も当然、それを使用してビルドする必要があります。古いシンボルを使用するには、サードパーティのライブラリにパッチを適用する必要がある場合があります。（古いGLIB_Cにはそのような関数がないため、有効な権限ではなく実際の権限を返すようにルビーにパッチを当てる必要がありました。何かを壊したかどうかはまだわかりません:)）。
デスクトップ環境 (ファイルの関連付け、MIME タイプ、アイコン、スタート メニュー エントリなど) との統合には、xdg-utils を使用します。ただし、Linux のすべての場合と同様に、ファイル名のスペースはあまり好きではないことに注意してください :)。各ターゲット ディストリビューションでこれらのことを必ずテストしてください。xdg の実装にはバグや癖がつきものです。
実際のインストールでは、さまざまなネイティブ パッケージ (rpm、deb など) を提供するか、独自のインストーラーを展開するか、ネイティブ パッケージ マネージャーをバイパスしてすべてのディストリビューションで動作するインストーラーを見つけることができます。そのために Autopackage (APbuild を作成したのと同じ人) を使用することに成功しました。
InstallBuilderを試してみることをお勧めします。クロスプラットフォームです (Windows、Linux、Mac OS X、Solaris、およびその他のほぼすべての Unix プラットフォームで動作します)。Intel、Motorola、GitHub、MySQL、Nokia/Trolltech、その他多くの企業で使用されているため、良い仲間になるでしょう:) バイナリインストーラーに加えて、クロスディストリビューション RPM と DEB パッケージも作成できます。
InstallBuilder は商用ですが、オープン ソース プログラムには無料のライセンスを提供し、mISV またはソロ開発者には非常に大幅な割引を提供しています。
バイナリで .tar.bz2 アーカイブを作成し、次のようにフィードを公開します。
<?xml version="1.0" ?>
<interface uri="http://mysite/myprog.xml"
xmlns="http://zero-install.sourceforge.net/2004/injector/interface">
<name>MyProgram</name>
<summary>what it does</summary>
<description>A longer description goes here.</description>
<implementation main='bin/myprog'
id="sha1new=THEDIGEST"
version='1.0'>
<archive href='http://mysite/myprogram-1.0.tar.bz2'
size='10000'/>
</implementation>
</interface>
GPG キーで署名します。0install.netのツールを使用して、ダイジェストを計算し、正しい形式で GPG 署名を追加できます。
次に、uri属性のアドレスにある Web サイトに配置します。ほとんどの Linux ディストリビューション (Ubuntu、Fedora、Debian、Gentoo、ArchLinux など) のユーザーは、次の方法でプログラムをインストールして実行できます。
0launch http://mysite/myprog.xml
彼らのシステムは定期的にアップデートをチェックします。デスクトップ環境ごとにさまざまな GUI がありますが、コマンドラインはどこでも機能します。
インスピレーションを得るために、既存のフィードのいくつかも見てください。
RPM を Debian に、APT を RHEL にインストールすることができます。
このプログラムを静的にリンクする場合、またはパッケージで配布するライブラリのみを動的にリンクする場合は、どのように配布するかは問題ではありません。最も簡単な方法は tar.gz で、これでうまくいきます。
OTOH がシステム ライブラリと動的にリンクされている場合、特にクライアントの他のアプリケーションと共有される動的ライブラリに依存している場合は、RPM、APT、またはその両方を実行する必要があります。
最善の方法はありません(普遍的に言えば)。tar.gz バイナリ。これで動作するはずです。
私はそのステータスを認識していませんが、追加の可能性を教えてください: Loki インストーラー. Loki は、ビデオゲームを Linux に移植する会社でした。2002 年にダウンしましたが、インストーラーは利用可能です。
InstallShield は Linux でも利用できます。ただし、ステータスについてはわかりません。
多くの人が tar.gz を使うよう提案していますが、やめてください。ユーザーに快適なインストール手順を提供したいと考えています。tar.gz は、最も低レベル、低品質、低ユーザビリティの選択肢の 1 つです。ご存知のように、基本的に何もしないため、どこでも機能します。
freedesktop.org と LSB の担当者は、どこに何かを配置するかについて非常に明確です。必要なのは、それを行うためのフレンドリーなプログラムです。Autopackage imhoには数字がありますが（私はそれが大好きです）、その古いにもかかわらず、autopackageとして配布されているプログラムを1つも見たことがありません。
慎重に評価しますが、人気がないという理由だけで、それを支持する勢いの一部になる可能性を逃してはいけません。それがあなたにとってもユーザーにとってもうまくいくのであれば、他のすべては問題ではありません。
私も職場でこれを調べましたが、「最善の方法」は本当にないことに同意する必要があります。アプリケーションがソースとして配布されている場合は、tar.gz にパッケージ化された make/configure メソッドを使用します。これは、Linux の世界ではかなり一般的なようです。
何をすべきかを理解する良い方法は、より大きな組織を見て、彼らがどのようにバイナリを配布しているかを確認することです。