（最新）Debianリポジトリに非常に古いバージョンしかないソフトウェアをインストールしたいと思います（そして追加する他のリポジトリはありません）。これを行うには、ソースからコンパイル/インストールする必要があります。
以前のバージョンを最初に削除する必要がありますか？これを行うことなく動作しますが、推奨される手順が何であるか、そうでない場合に問題が発生するか（そしてどの手順）を知りたいです。
たとえば、依存関係に問題がありますか？それとも、インストールはどのようにして他のインストールから適切に隔離されていますか？
答え1
ソースからインストール（使用）する場合sudo make install、あなた設置場所の選択を担当します。
ソースからインストールした場合は、以下のパッケージの多くがデフォルトでインストールされますが、ソフトウェアをビルドしてからインストール/usr/localする前に、ソースパッケージのビルド手順を確認するか、試用版のインストールを実行する必要があります（通常はビルドのガイドラインを参照make -n install）。の。
下に/usr/local設置する場合通常ディストリビューションによって提供されるパッケージのバージョンを妨げてはいけません/usr/local/bin。/usr/bin/bin通常パッケージのバージョンよりも優先されます。
したがって、インストール後はすべてが正常になります。ただし、展開がアップグレードされ、ローカルにビルドされたインストールが展開パッケージのインストールより古い場合、後で問題が発生する可能性があります。を使用してローカルにビルドされたソフトウェアをインストールする場合は、sudo make installソースパッケージにそのsudo make uninstall手順が含まれる場合と含まれない場合があります。ビルドディレクトリを削除すると、Makefile正しい削除手順を含む可能性がある自動作成ディレクトリが消える可能性があります。
したがって、を使用している場合は、sudo make installインストールプロセスの出力を記録したり、後で手動で削除したりできるように、インストール段階で追加されたファイルをメモしておく必要があります。事前に計画してください。 （問題のシステムが単一目的のサーバーである場合は、ソースから構築された唯一のソフトウェアである可能性があるため、/usr/local/階層内のすべてのファイルはそのインストールによって生成された可能性があります。したがって、/usr/localアップグレード後にすべてのファイルを簡単に削除することが可能な場合があります。バージョン）。
ソースパッケージにこのdebian/rulesファイルが含まれている場合、ソースコードには実際のDebianパッケージを構築するために必要な設定がすでに含まれています。この場合、通常のソースビルド手順を代わりに使用でき、dpkg-source -b結果として.debパッケージマネージャを使用してインストールできる1つ以上のパッケージを作成する必要があります。
パッケージ名がディストリビューションの対応する標準バージョンと同じですが、ローカルにビルドされたパッケージのバージョンが高い場合、ローカルにビルドされたパッケージはディストリビューションのバージョンを置き換えるために自動的に使用されます。ディストリビューションが提供するアップデートのインストールと同様に、パッケージマネージャは自動的に古いバージョンのパッケージを削除し、新しいバージョンに置き換えます。
（ビルドしたパッケージに暗号署名の追加手順を実行しない限り、使用するパッケージ管理ツールに応じてパッケージマネージャから警告を受け取ることができますが、パッケージを直接構築したので信頼できます。）
この場合、ディストリビューションパッケージリポジトリのソフトウェアバージョン番号がローカルにビルドされたパッケージより高い場合、パッケージマネージャは標準パッケージのアップグレードと同様に自動的にアップグレードを提案します。
一般的なソースコードのビルドガイドラインとDebian関連のガイドラインがありますdpkg-source -b。ビルド中のパッケージが特定のライブラリに依存している場合は、そのライブラリの互換性のあるバージョンをインストールする必要があります。開発キットコンパイラがライブラリの使い方を知ることができるようにします。
開発パッケージ名は通常、-devサフィックスが追加された対応するライブラリパッケージ名と同じですが、ライブラリパッケージ名には、一部の開発パッケージ名から省略されたバージョン番号が含まれることがあります。 （この場合、以前のバージョンとの互換性のために複数のバージョンのライブラリがある可能性がありますが、開発パッケージには両方のバージョンが含まれているか、最新バージョンのみが含まれています。）
新しいバージョンを正常にコンパイルしたようですが、これはあなたには関係がないかもしれません...しかし、ソースからソフトウェアの最新バージョンを構築するときに、特定のライブラリまたは他のライブラリの最新バージョンが必要になることがあります。デプロイ可能...このライブラリの最新バージョンには、コンパイルするには他のライブラリの最新バージョンが必要です...など。依存関係チェーンをナビゲートし、必要なライブラリのローカルバージョンを構築することは可能ですが（必要なライブラリの数が多すぎない場合）、あまり遠くないことが重要です。 1 つまたは 2 つの特殊ライブラリの新しいバージョンを提供することは問題ありませんが、複数のシステムコンポーネントで使用されるアップグレードされたバージョンのライブラリの構築を開始する場合は、最新のディストリビューションに切り替えることを検討する必要があります。新しいバージョンをローカルでコンパイルglibcし、システム全体で使用するためにインストールするのは当然です。
答え2
TL; DRの答えは、すべてが期待どおりに機能する場合は、自分がしていることを知らない、または危険だと感じない限り、「実行中のシステムに触れないでください」です。 :) ただし、apt remove <software>使用するのは比較的安全であり（または類似）、バージョンの競合または非常にこのパスを介して壊れる依存関係はほとんどありません（aptを介してインストールされたソフトウェアの場合）。
最初のステップとして、ソフトウェアの依存関係を手動で確認できます。
ldd --verbose <program>
しかし、これはすぐに複雑になる可能性があります。私のアドバイスは、古いソフトウェアからライブラリがインストールされたという理由だけで、盲目的にライブラリを削除しないでください。他のプログラムでも使用できます。
様々なバージョンのライブラリは、通常、適切な命名規則によってよく「分離」される。残念ながら、破損した共有ライブラリをインストールすると、常に問題が発生します。この場合、ライブラリを再インストールするか、ソフトウェアに完全に依存する必要があります。どのソフトウェアを最初にインストールするかを慎重に検討することで、後続の問題を軽減できます（仮想マシンのミラーを設定してそこでテストすることもできます）。
もちろん、上記は共有ファイルにのみ適用されます。 /home/にインストールされているファイルとディレクトリは比較的安全に削除できます。 Gem、Shard、Pythonパッケージなどのアイテムには例外があるかもしれませんが、比較的簡単に再インストールできます。また、アクセスキーまたはロック解除コードを生成した場合は、削除する前にバックアップを作成してください。
もちろん、このトピックへの答えは「ただしなさい」から「決して触れないでください」までさまざまであり、このトピックを取り巻く確かに多くの意見があります。
お役に立てば幸いです。
答え3
/usr/localLinuxでは、ソースとソース間に新しいソフトウェアをインストールするのが標準的な方法です。/optつまり、インストールされているソフトウェアをアンインストールする必要はありません。