インストール済みのアプリケーションに対するソースからのコンパイルの影響


8

私は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-それは満たされますか?

私はこれを説明する良い情報源をオンラインで見つけようと努めてきました。何か提案があれば教えてください。


あなたが意図的にパッケージマネージャを回避する場合は、上のどのような地球はあなたはその後、インストールするものを認識するだろうと思わせますか?
Shadur 2012

@Shadurこの質問のこの側面は、基本的に、を使用してソースからソフトウェアをインストールするときに何が起こるかという問題に帰着しmake installます。答えから明らかなのは、ファイルがインストールプレフィックス内のディレクトリにコピーされることだけです(ただし、これは、一部の構成ファイルが/etc挿入されたり、初期値を表す動的に変更可能なデータが含まれたりする可能性があることを示しています)何かの状態がに入れられるかもしれません/var)。ただし、それが明確でないと思われる場合は、回答を編集して説明させていただきます。
Eliah Kagan 2012

@EliahKagan私は主にフィリップに対してレトリックになっていた。
Shadur 2012

回答:


12

圧倒的多数の.debパッケージは、公式リポジトリから提供されているかどうかに関係なく、プレフィックスを付けてインストールします/usr

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

少数のパッケージ/が接頭辞として使用されます。たとえば、bashパッケージはbash実行可能ファイルを/binではなくに配置し/usr/binます。これは、(リカバリモードなど)シングルユーザーモードで実行すると、マルチユーザモードを起動する(しかし、多くの場合、ネットワーク共有のいくつかの種類を実装するための機能が含まれていることを、覚えて裸の必需品を提供するパッケージです...場合に/usrされてリモートファイルシステム)。

ごく一部の.debパッケージ、主にQuicklyで作成されたパッケージは、パッケージ固有のフォルダーを作成し、/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-prefixedディレクトリの前に表示される場合など/usr/bin)。

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

    プログラムまたはライブラリの両方のバージョンを実際に使用していない場合は、多くの場合、使用していないものを削除する必要がありますが、限られた状況では、依存関係を満たすためにパッケージをインストールしたままにすることもできます。

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

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

依存関係を満たすために:

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

    同様に、インストールするソフトウェアが依存するパッケージによって提供されるファイルを手動で削除した場合でも、ソフトウェアは少なくとも完全にインストールしようとします。(通常、それを目的に利用しようとするべきではありません。誤った情報に基づいて動作するパッケージマネージャーは、ほとんどの場合悪いことです。)

したがって、必要なソフトウェアのバージョンを提供するパッケージが見つからない場合は、.debコンパイルしたソフトウェアから独自のパッケージを作成し、そのパッケージからインストールする必要があります。次に、パッケージマネージャーは何が起こっているかを認識します。自分用のパッケージを作成することは、他の人のコンピューターでうまく機能する必要がないため、実際にはそれほど難しくありません。(しかし、私はそれが現在述べられているように、あなたの質問の範囲外であるかもしれないと感じています。)


詳細な回答をありがとうございました。多くのコンセプトが明確になりました
フィリップドロザリオ2012

5

ソフトウェアセンターから、またはAPTコマンド(apt-getaptitude)、またはdpkgパッケージ管理システムを使用してインストールするものは、パッケージ管理システムに認識されています。dpkgは低レベルのパッケージ操作ツールです。APTなどはdpkg、実際のインストールを実行するために呼び出し、依存関係とパッケージのダウンロードを処理する高レベルのツールです。

ソースからプログラムをコンパイルしても、パッケージマネージャーはそのプログラムを認識しません。Linuxでの慣習は、物事を追跡するのに苦労したり、インストールを上書きしたりするのに苦労する必要があります。

  • /bin/lib/sbin/usrパッケージマネージャに予約されています。
  • それ以外/usr/localはシステム管理者向けです—そこのディレクトリ階層を尊重してください。ただし、自分でファイルを管理する必要があります。

Ubuntu 10.04でvim / gvimを7.3にアップグレードする最良の方法を参照してください最新バージョンのソフトウェアを入手する方法のリストについては、PPAがある場合、最も簡単な方法はPPAを取得することです。バイナリパッケージを入手するか、ソースからコンパイルする場合は、stowを使用して手動でインストールしたソフトウェアを管理することをお勧めします。または、独自の.debパッケージを作成します —作業は増えますが、頻繁にアップグレードする場合(通常、次のマイナーバージョンのパッケージの再実行は非常に高速です)、または同じディストリビューションを実行している多くのマシンにデプロイする場合に効果があります。

ほとんどのプログラムでは、を実行する./configure && make && sudo make installと、プログラムはの下にインストールされ/usr/localます。Doがソースに付属のマニュアルを確認する(一般的に呼ばれるファイル内READMEまたはINSTALL)、または実行./configure --helpこれが事実であることを確認します。プログラムがの下/usr/localにインストールされている場合、パッケージマネージャーによって提供されるバージョンに干渉しません。/usr/local/binシステムで最初に来るPATHmake install管理者(root)として実行する必要があることに注意してください。ルートとしてコンパイルしないでください。上記のように、に直接インストールするのではなく、ストウを使用することをお勧めし/usr/localます。


1

これはパッケージと他の多くのものに依存します

  1. 使用される命名規則-バイナリにはファイル名にバージョン番号が含まれていますか
  2. インストール場所-デフォルトではoptにありますが、パッケージバージョンは/ usrにあります
  3. より多くの可能性

要するに
、一般的な答えはありません。パッケージに大きく依存します。ソースからコンパイルするのではなく、可能であれば公式の+1 PPAを使用する必要があります。


1
ソースからコンパイルされたプログラムまたはライブラリがにインストールされるのは、実際には非常に珍しいことです/opt/usr/localは標準のプレフィックスであり、/usrデフォルトのプレフィックスであるよりも一般的です/opt/opt特定のアプリケーション用に名前が付けられた専用ディレクトリ内にインストールされるソフトウェアで最も一般的に使用されます(たとえば、Fooと呼ばれるアプリケーションがすべてのファイルとともににインストールされる場合があります/opt/foo)。
Eliah Kagan 2012
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.