Ich habe gelesen, dass die Installation inoffizieller Repositories in RedHat keine gute Idee ist. Also habe ich versucht,NodeJSauf dem RH-Server und ich sah, dass die Git-Version 1.7.1 war. Unser Team verwendet 1.9 auf ihrem lokalen Ubuntu. Ich habe mich also gefragt, ob ich installiereGit 1.9 - Installationshandbucherstens (würde dies das System in irgendeiner Weise beschädigen/instabil machen? – das ist auch nötig, weil ich anschließend den Git-Server einrichten muss) und würde dies yum groupinstall "Development Tools"
zu Konfliktproblemen irgendeiner Art führen?
Ich versuche, hier sehr vorsichtig zu sein, da dies der Server ist, den das gesamte Team verwenden wird, und ich nicht die Möglichkeit habe, einen Snapshot zu erstellen, auf den ich zurückgreifen könnte, falls etwas passiert ...
==========================================================================================================
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)
Antwort1
würde dies das System in irgendeiner Weise beschädigen/instabil machen?
Wenn Sie Software benötigen, die nur in einem bestimmten Repo verfügbar ist, würde ich wahrscheinlich dieses verwenden. Stellen Sie jedoch zuerst sicher, dass Sie sie wirklich benötigen.
Die Probleme treten auf, wenn die Repos/RPMs schlecht konzipiert sind. Dies kann zu Situationen führen, in denen yumeine höhere Version eines bestimmten Pakets installiert wird, weil es im anderen Repo unter demselben Namen verfügbar ist, dann aber einige Software aus dem Basiskanal nicht mehr installiert werden kann, weil sie mit einer früheren Versionsnummer erstellt wurde. Dies kann zu einem Clusterfrack eines Problems führen, das normalerweise nicht intuitiv gelöst oder rückgängig gemacht werden kann.
Wenn Sie etwas anderes als EPEL verwenden, würde ich das Repo einfach mit konfigurieren, enabled=0sodass das Repo generell deaktiviert ist, aber wenn Sie es brauchen, können Sie einfach sagen yum install packageName --enablerepo=repoName. Dies verhindert, dass etwas aus diesem Repo versehentlich installiert wird.
Natürlich besteht auch das Problem, dass Basiskanalpakete aufgrund der Qualitätssicherung und der Breite ihrer Installationsbasis per Definition stabiler sind als die neuesten und besten.
Daher habe ich mich gefragt, ob es zu Konfliktproblemen kommen würde, wenn ich zuerst Git 1.9 installiere [...] und dann die Yum-Gruppeninstallation „Development Tools“ ausführe.
Möglicherweise müssen Sie einfach sehen, was es bewirkt. Letztendlich liegt es am Repo-Betreuer, sicherzustellen, dass die Benutzer ihrer Repositories so reibungslos wie möglich arbeiten können. Daher ist es schwer zu sagen, was Sie bekommen, wenn Sie sich von den bekannteren Repositories entfernen.
Ich würde zuerst die Entwicklungstools erstellen und ein hinzufügen, --disablerepo=repoNamedamit das installiert wird, und einfach hoffen, dass der Repo-Betreuer das als Referenzpunkt verwendet hat, als er entschieden hat, wie diese RPMs erstellt werden sollen. Das scheint die beste Erfolgsaussicht zu haben. Ein groupinstallwird mehr Pakete enthalten (direkt und für Abhängigkeiten), als wenn eine bestimmte Anwendung von installiert wird. Wenn also etwas aus dem Basiskanal mit dem RPM des inoffiziellen Repos in Konflikt gerät, sollte es einfacher sein, es stückweise zu entfernen und die Pakete des Basiskanals zu entfernen.
Ich versuche, hier sehr vorsichtig zu sein, da dies der Server ist, den das gesamte Team verwenden wird, und ich nicht die Möglichkeit habe, einen Snapshot zu erstellen, auf den ich zurückgreifen könnte, falls etwas passiert ...
Wenn dies der Fall ist, würde ich bei jedem Update die Liste mit den Updates sorgfältig durchsehen und sicherstellen, dass sie aus den richtigen Repositories stammen, bevor Sie mit der Installation fortfahren.