商用製品でこれを数回経験したことから、サポートされている各プラットフォームのネイティブ インストーラーを使用することが最善の答えだと思います。それ以外のものはエンドユーザーに不快な体験をもたらします。実際には、サポートしたいすべてのプラットフォームでテストする必要があるため、それぞれのパッケージを維持することはそれほど大きな負担ではありません.聞いたことのないものも含めて、そこにあるすべてのプラットフォームで「正常に動作する」バイナリを作成できるという考えは、実際にはそれほどうまく機能しません.
最初にサポートするプラットフォームを 1 つまたは 2 つ選択し (Red Hat と Ubuntu をお勧めします)、ユーザーの要求に応じて追加のインストール パッケージを作成することをお勧めします。おそらく、そのプラットフォームでのパッケージ化とテストの時間と労力をカバーする適度な料金で、追加のプラットフォームをサポートする意思があることを知らせてください。プラットフォームが大きく異なる場合は、継続的なサポートに対して追加料金が必要になる場合があります。
ああ、このようなシナリオでの仮想マシンの価値はいくら強調してもしすぎることはありません。サポートするプラットフォームごとに VM を構築する必要があり、さまざまな構成を簡単にテストできるように、プラットフォームごとに複数の VM を構築する必要があります。
ここにはたくさんの良い答えがありました（私のものも含まれています:)）。ただし、これはバイナリ互換性に関するものです (心配する必要があります)。
インストーラーについては、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 またはソロ開発者には非常に大幅な割引を提供しています。お気軽にお問い合わせください。