インストールされたアプリケーションに対するソースコンパイルの影響

インストールされたアプリケーションに対するソースコンパイルの影響

Ubuntu 12.04を使用してください。package xリポジトリにバージョン1.7(およびすべての依存関係)がインストールされていますが、バージョン1.8でのみ利用可能ないくつかの機能が必要なので、ソースtarをダウンロードしてコンパイルするとします。

./configure  
make  
make install
  • 既存の1.7バイナリを上書きしますか?
  • 既存のバイナリを上書きすると、パッケージマネージャは新しいバージョン(1.8)を反映し、package x将来のパッケージマネージャを更新できますか?
  • package y- に依存関係がある場合はpackage x 1.8満たされますか?

私はこれを説明する良いソースをオンラインで見つけようとしました。提案があれば教えてください。

ベストアンサー1

.deb公式リポジトリが提供されているかどうかに関係なく、ほとんどのパッケージはプレフィックスとしてインストールされます/usr

これは、ユーザーが実行する実行可能ファイルが入っている/usr/bin/usr/sbin(または/usr/gamesゲームの場合)、共有ライブラリが入っていて、プラットフォームに依存しない共有/usr/libデータが入っていて/usr/share、ヘッダファイルが入り/usr/include、自動インストールされたソースコードが入ることを意味します/usr/src

小さなパッケージセットが/プレフィックスとして使用されます。たとえば、bashパッケージbashは。特定の種類のネットワーク共有...場合に備えてリモートファイルシステム)。/bin/usr/bin/usr

.deb主に以下を使用して作成された小規模パッケージのコレクションです。早く、内部にパッケージ固有のフォルダを作成し、/optすべてのファイルをここに配置します。それに加えて、ほとんどの場合、/optシステムのパッケージマネージャを使用しないがソースでコンパイルしない実行可能なインストーラからインストールされたソフトウェアによって場所が使用されます。 (たとえば、MATLABなどの独自のプログラムをインストールする場合/opt

これとは対照的に、ソースアーカイブをダウンロードするとき(またはBazaarやgitなどのリビジョンコントロールシステムからソースコードをインポートするとき)をビルドしてインストールします。通常/usr/local特に指定しない限り、プレフィックスにインストールします。これは、実行可能ファイルが/usr/local/bin/usr/local/libまたはにあり、/usr/local/gamesライブラリが背中にあることを意味します/usr/local/lib

いくつかの例外があります。一部のプログラムはデフォルトでプレフィックスにインストールされるため、/usrパッケージ内の同じプログラムのインストールを上書きします。.deb通常、これをビルドする./configure --prefix=/usr/localのではなく実行して./configureこれを防ぐことができます。もう一度強調しますが、通常これは必要ありません。

(このため、構築してインストールするソースコードをシステム全体で使用するのは完璧です/usr/local/src。これはこの目的のために存在します。)

パッケージのバージョンがインストールされ/usr、ソースからインストールされたバージョンが次の場所にあるとします/usr/local

  • インストールされたパッケージのファイルは上書きされません。

    通常、コマンドラインからプログラムを手動で呼び出すと、最新バージョンが実行されます(実行可能ファイルがインストールされている場所が/usr/local/bin環境PATH変数にあり、その/usrプレフィックスが付いたディレクトリの前に表示される場合/usr/bin)。

    ただし、メニューまたは検索によって作成されアクセスされるランチャーにはいくつかの問題がある可能性があります。さらに、異なるバージョンのライブラリが異なる場所にインストールされている場合、どのソフトウェアがどのバージョンを使用するかを決定するのが少し複雑になることがあります。

    実際にそうでない場合使用2つのバージョンのプログラムまたはライブラリがある場合は、一般的に使用されていないバージョンを削除する必要がありますが、制限されている場合は、依存関係を満たすためにインストールされたパッケージを維持する必要があります。

ただし、何らかの理由でファイルを上書きした場合(たとえば、ソースコードが/usr代わりにインストールされている場合/usr/local):

  • パッケージマネージャは、自分がインストールするソフトウェアがどのように変更されたかを知ることはできません。以前のバージョンがインストールされていると思います。悪い問題を引き起こす可能性があります。このような状況を避けるべきです。このような状況が発生した場合は、元のディレクトリsudo make uninstall(通常はディレクトリにあります)からインストールしたソフトウェアを削除し、上書きしたファイルを提供するパッケージを削除する必要があります。/usr/local/src/program-or-library-nameいいえソースからインストールされているバージョンを削除して復元します。その後、目的のバージョンを再インストールします。

依存関係を満たす場合:

  • .debパッケージがソースからインストールされたソフトウェアに依存し、ソースからインストールされたバージョン(またはそれ以上)が必要な場合、パッケージはいいえ正常にインストールされました。 (またはより正確には「インストール」することはできますが、「構成」されていないため使用できません。)それを解決するソフトウェアがあります。

    同様に、インストールされているソフトウェアが依存するパッケージによって提供されるファイルを手動で削除しても、ソフトウェアは少なくとも完全にインストールを試みます。 (通常、何らかの目的でそれを悪用しようとしないでください。エラーメッセージに基づいて機能するパッケージマネージャはほとんど常に悪いことです。)

したがって、目的のソフトウェアバージョンを提供するパッケージが見つからない場合は、.debコンパイルされたソフトウェアから独自のパッケージを作成し、そのパッケージからインストールする必要があります。その後、パッケージマネージャは何が起こったのかを知ります。実際、他人のコンピュータで正しく動作する必要がない独自の使用のためのパッケージを作成することはそれほど難しくありません。 (しかし、現在の表現方法を考えると、これはあなたの質問の範囲から外れる可能性があると思います。)

おすすめ記事