ソフトウェア構築時の依存関係の問題[閉じる]

重要な要約：/usr/local独自のソフトウェアを使用するか、バックポートしてパッケージ化します。

一般的なものから始めましょう。分布は一貫した単位です。明らかに、それは合理的な範囲内でユーザーが何をしたいのかをサポートするために存在します（項目4を参照）。Debian 社会契約）、しかし最初にそれ自体をサポートする必要があります。特に、ライブラリはディストリビューションの他のソフトウェアに依存しており、パッケージ-dev（またはdevelRPM側のリーダー）が構築される可能性があるために含まれています。パッケージソフトウェアは使用します。分布。ディストリビューションの上にソフトウェアを構築するときは、ディストリビューションに含まれているライブラリが要件を満たしている場合は非常に良いです。ただし、そうでない場合は、アップグレードするためにディストリビューションを調整しないでください。 。

一部の開発環境ではすでにこれを処理しています。 Pythonには仮想環境があり、Rubyには同様の環境があり、JavaとNPMは独自のプロジェクト固有の依存関係ツリーを管理するなどのタスクを実行します。 C/C++ エコシステムには実際にこのようなものはありません。ただし/usr/local、コンパイラが古すぎる場合を含む多くの場合にこれが非常に適している可能性があります。

実際、C/C++ エコシステムにはいくつかの実現可能なソリューションがあります。

• 最先端の技術が必要な場合は、「不安定な」システムとして開発できます。完全なシステムである必要はありません（Debianの次のバージョンの開発を支援したい場合にのみこれを行う必要があります）。 chrootはこれに対してうまく機能します。また、「不安定」とは、システムではなくABIの安定性を意味します。全体的な安定性。

• 自分の依存関係を手動で管理するには、次の/usr/local点を確認してください。拾って入れる管理バージョン）。

• いくつかのアップグレードされた依存関係が必要な場合は、次を使用することをお勧めします。バックポート。この回答バックポートをインストールする方法、または直接ビルドする方法について説明します。これにより、現在の安定版よりも最新バージョンのパッケージを安全な方法で使用できます。これはスケーラビリティが高く、多くの組織が内部的にバックポートされたパッケージの独自のストレージを維持します。

最も重要なことは、構築中のソフトウェアをパッケージ化する方法を学ぶことが価値があるということです。これにより、ディストリビューションツールが依存関係を引き続き使用できるようになり、ソフトウェアを別のシステムにインストールしたりアップグレードしたりするのに役立ちます。 Vincent Bernaは素晴らしいです。実用的な Debian パッケージング技術はあなたが目標にすばやく到達するのを助けます。