☰

ポータブルLinux商用クローズドソースプログラムを配布するには？ [閉鎖]

tag-icon • tag-icon dynamic-linking shared-library deployment
ポータブルLinux商用クローズドソースプログラムを配布するには？ [閉鎖]

まず、同様の質問を見つけました。ポータブルLinuxアプリケーションを作成するには？しかし、これは私の問題を実際に解決しません。アプリケーションを移植可能にするためにコンパイルする方法の方が重要です。私はすでに実行方法を知っています（少なくとも私は知っていると思います）。展開についてはあまり説明しません。方法。

これが私の状況です。私たちは顧客の問題を解決するために雇われたので、顧客に販売する目的でプライベートソースアプリケーションを開発します。しかし、我々はそれがどこで実行できるかについての詳細を得ることができませんでした。つまり、ディストリビューション、カーネルバージョンなどを意味します。作業は非常に簡単で、低レベルのドライバや移植性を複雑にするものには依存しません。しかし、私たちはいくつかのサードパーティのライブラリに依存しています。以下は単純な依存関係スキームです。

app --+-- libA
      |          +-- lib1
      +-- libB --+-- lib2
                 +-- lib3

そのうち、libA、B、lib1、2、3は適切なライセンス（LGPL、ASL、BSD）を持つオープンソースプロジェクトです。コンパイル後、私たちのプログラムの共有依存関係は、libA、libB、lib1、lib2、lib3、libc、libm、libz、libstdc++、libpthreadなどのいくつかのシステムライブラリになります。すべてが動的に接続されています。

これでターゲットディストリビューションがないので、それをすべてのパッケージングシステム（.debなど）とは無関係にしたいと思います。直接的な依存関係（libAとlibB）は一般的ではないため、アプリケーションに提供することは確実な選択です。 lib1、2、3は実際にはより一般的ですが（つまり、その1つがlibpngです）、ターゲットシステムにインストールされるかどうかはまだわかりません。私たちはそれらをすべて最終パッケージに含めることにしました。

私たちはシステムライブラリで何をすべきかわかりません。この問題にどのように対処する必要がありますか？私たちは彼らが正しいライブラリを持って最善を尽くすと仮定していますか？この場合、ライブラリの1つが変更され、アプリケーションの動作が停止した場合、1〜2年後にどうなりますか？

これらすべて（libstdc ++、glibcなど）をソフトウェアと共に配布する必要がありますか？これは正しいとは思われず、ライセンス条項に違反する可能性があると思います。私は過去にこれらのライブラリのうち[少なくとも]いくつかの独自のコピーを持っているいくつかのプログラムを使用したことがあることを知っていました。すべてが動作を停止しました（偶然これを発見しました）。

この状況は通常どのように処理されますか？

ベストアンサー1

Linuxで移植可能なバイナリ実行可能ファイルを実装する厳密に正しい方法は次のとおりです。Linux標準ライブラリそしてその詳細仕様。 LSBは、特定のライブラリバージョン（またはそのバージョンとの互換性）を指定して、互換性のあるディストリビューション全体でバイナリ互換性を生成するためのものです。 LSB（または少なくとも以前のバージョン）は次のように定式化されています。ISO/IEC 23360。 LSBライブラリ（および付属のライブラリ）にのみリンクするプログラムを構築すると、これらすべてのシステム間で移植可能です。

LSBはパッケージのRPM形式を指定するため、1つだけを生成するだけです（厳密に）。パッケージマネージャとの統合をあきらめれば、タールボールで十分です。

お客様に関する具体的な事項は次のとおりです。

私たちは彼らが正しいライブラリを持って最善を尽くすと仮定していますか？

かなり単純なLSB互換プログラムは、おそらく多くのシステムでそのまま実行されるので、そうすることができます。

また、一部のディストリビューションでは、RHEL と SUSE を含む LSB 準拠を提供しようとします。一部は、適切な依存関係をもたらす特定のパッケージを介して提供します。例えば ​​Debian ではセットlsbこれは他の多くのものを引き出し、lsb-core順番に適切な依存関係を引き出します。ソフトウェアを実行するには、ターゲットシステムにこれらのパッケージをインストールする必要があります。

LSBはこれ以上人気がなくなり、多くのシステムとの正式な互換性が低下しましたが、実際にはかなり広範囲のアプリケーションに移植することができます。コンプライアンスに憧れるいくつかのシステムでさえ、もっと曖昧な点を見逃してしまうかもしれませんが、一般的な目的のためにこれは一般的に重要ではありません（そして同じプログラムがおそらく次のシステムで実行されます）。いいえLSBに準拠してください。）

この場合、ライブラリの1つが変更され、アプリケーションの動作が停止した場合、1〜2年後にどうなりますか？

アプリの動作が停止すると、アプリの動作も停止します。これはビジネスプロセスの問題です。

これらすべて（libstdc ++、glibcなど）をソフトウェアと共に配布する必要がありますか？

おそらくそうではありません。特に、libc の場合、システムで複数のバージョンを同時に使用すると、ランタイム互換性の問題が発生する可能性があります。しかし、バンドリングに適した他のlibc実装があります。

ほとんどのライブラリは正常にバンドルできますが、ライブラリのプロビジョニングは保守およびセキュリティの問題になることが多いため、可能であればそれを避けることをお勧めします。ライブラリでバグやセキュリティの欠陥が見つかった場合は、各コピーを追跡して交換パッケージを受け取るよりも、システム内の1つの場所（リリースで問題が解決する場所）で更新する方が簡単で信頼性が高くなります。 ）。

より実用的なステップで、顧客にどこで実行したいのかを尋ねることもできます。過度に情熱的かもしれません。

おすすめ記事