RedHatに非公式リポジトリをインストールするのは良くないと読んだので、インストールしようとしましたノードJSRHサーバーでgitのバージョンが1.7.1であることがわかりました。私たちのチームはローカルのUbuntuで1.9を使用しています。git 1.9まず (これによってシステムが壊れたり不安定になったりするでしょうか? - 後で git サーバーをセットアップする必要があるため、これも必要です)、次に、yum groupinstall "Development Tools"
これによって何らかの競合の問題が発生するでしょうか?
これはチーム全体が使用するサーバーであり、何かが起こった場合にロールバックするためのスナップショットを作成するオプションがないため、ここでは非常に慎重になるようにしています...
==========================================================================================================
Package Arch Version Repository Size
==========================================================================================================
Installing:
byacc x86_64 1.9.20070509-7.el6 rhel-x86_64-server-6 48 k
cscope x86_64 15.6-6.el6 rhel-x86_64-server-6 136 k
ctags x86_64 5.8-2.el6 rhel-x86_64-server-6 147 k
diffstat x86_64 1.51-2.el6 rhel-x86_64-server-6 29 k
doxygen x86_64 1:1.6.1-6.el6 rhel-x86_64-server-6 2.4 M
flex x86_64 2.5.35-8.el6 rhel-x86_64-server-6 286 k
gcc-c++ x86_64 4.4.7-4.el6 rhel-x86_64-server-6 4.7 M
gcc-gfortran x86_64 4.4.7-4.el6 rhel-x86_64-server-6 4.7 M
git x86_64 1.7.1-3.el6_4.1 rhel-x86_64-server-6 4.6 M
indent x86_64 2.2.10-7.el6 rhel-x86_64-server-6 115 k
intltool noarch 0.41.0-1.1.el6 rhel-x86_64-server-6 58 k
libtool x86_64 2.2.6-15.5.el6 rhel-x86_64-server-6 564 k
patchutils x86_64 0.3.1-3.1.el6 rhel-x86_64-server-6 95 k
rcs x86_64 5.7-37.el6 rhel-x86_64-server-6 173 k
redhat-rpm-config noarch 9.0.3-42.el6 rhel-x86_64-server-6 59 k
swig x86_64 1.3.40-6.el6 rhel-x86_64-server-6 1.1 M
systemtap x86_64 2.3-4.el6_5 rhel-x86_64-server-6 26 k
Installing for dependencies:
libgfortran x86_64 4.4.7-4.el6 rhel-x86_64-server-6 265 k
libstdc++-devel x86_64 4.4.7-4.el6 rhel-x86_64-server-6 1.6 M
perl-Error noarch 1:0.17015-4.el6 rhel-x86_64-server-6 29 k
perl-Git noarch 1.7.1-3.el6_4.1 rhel-x86_64-server-6 28 k
perl-XML-Parser x86_64 2.36-7.el6 rhel-x86_64-server-6 224 k
systemtap-client x86_64 2.3-4.el6_5 rhel-x86_64-server-6 3.4 M
systemtap-devel x86_64 2.3-4.el6_5 rhel-x86_64-server-6 1.4 M
Transaction Summary
==========================================================================================================
Install 24 Package(s)
答え1
これにより、システムが何らかの形で壊れたり不安定になったりするでしょうか?
特定のリポジトリでのみ利用可能なソフトウェアが必要な場合は、おそらくそれを使用するでしょう。まず、それが本当に必要かどうかを確認してください。
リポジトリ/rpm の設計が不十分な場合に問題が発生します。これにより、yum
特定のパッケージの上位バージョンが他のリポジトリで同じ名前で利用できるためインストールされるものの、ベース チャネルの一部のソフトウェアは以前のバージョン番号に対してビルドされているためインストールされなくなるという状況が発生する可能性があります。これにより、通常は直感的に解決したり、取り消したりできない、問題が山積みになる可能性があります。
EPEL 以外のものを使用する場合は、リポジトリを で構成して、enabled=0
リポジトリが通常は無効になるようにします。ただし、必要な場合は と指定するだけで済みますyum install packageName --enablerepo=repoName
。これにより、そのリポジトリから何かが誤ってインストールされるのを防ぐことができます。
もちろん、ベース チャネル パッケージは、QA が実施されていることとインストール ベースの広さのせいで、最新のパッケージよりも定義上安定しているという問題もあります。
そこで、まず git 1.9 をインストールし [...]、yum groupinstall "Development Tools" を実行すると、何らかの競合問題が発生するのではないかと思いました。
潜在的には、それが何をするのかをただ見てみる必要があります。最終的には、リポジトリを使用する人々が可能な限りスムーズに利用できるようにするのはリポジトリのメンテナーの責任なので、よく知られているリポジトリから離れると、何が得られるかを知ることは困難です。
まず開発ツール--disablerepo=repoName
に を追加してインストールし、リポジトリのメンテナーがこれらの RPM の構築方法を決定する際にそれを参照ポイントとして使用することを期待します。これが成功する可能性が最も高そうな方法のようです。groupinstall
には、特定のアプリケーションを からインストールするよりも多くのパッケージ (直接および依存関係用) が含まれます。そのため、ベース チャネルの何かが非公式リポジトリの RPM と競合する場合は、それを分割してベース チャネル パッケージを削除する方が簡単なはずです。
これはチーム全体が使用するサーバーであり、何かが起こった場合にロールバックするためのスナップショットを作成するオプションがないため、ここでは非常に慎重になるようにしています...
その場合は、インストールを続行する前に、各アップデートの更新リストを注意深く確認し、正しいリポジトリからのものであることを確認してください。