Estaba leyendo que instalar repositorios no oficiales en RedHat no era una buena idea. Así que estaba intentando instalarNodoJSen el servidor RH y vi que la versión de git era 1.7.1. Nuestro equipo está usando 1.9 en su ubuntus local. Entonces me preguntaba si instalogit 1.9primero (¿esto rompería/inestabilizaría el sistema de alguna manera? También necesito esto porque necesito configurar el servidor git después) y ¿esto yum groupinstall "Development Tools"
resultaría en problemas de conflicto de algún tipo?
Estoy tratando de ser muy cauteloso aquí porque es el servidor que usará todo el equipo y no tengo la opción de crear una instantánea para retroceder en caso de que suceda algo...
==========================================================================================================
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)
Respuesta1
¿Esto rompería/inestabilizaría el sistema de alguna manera?
Si necesita software que solo está disponible en un repositorio determinado, probablemente lo utilizaría. Solo asegúrate de que realmente lo necesitas primero.
Los problemas entran en escena cuando los repositorios/rpms están mal diseñados. Esto puede llevar a situaciones en las que yumse instalará una versión superior de un paquete en particular porque está disponible en el otro repositorio con el mismo nombre, pero luego parte del software del canal base ya no se instalará porque se creó con un número de versión anterior. Esto puede crear una serie de problemas que generalmente no se resuelven intuitivamente ni se evitan.
Si usa algo que no sea EPEL, simplemente configuraría el repositorio enabled=0para que esté deshabilitado en general, pero si lo necesita, simplemente diga yum install packageName --enablerepo=repoName. Esto evita que algo de ese repositorio se instale accidentalmente.
Por supuesto, también existe el problema de que los paquetes de canales base son, por definición, más estables que los últimos y mejores simplemente por el control de calidad que se realiza sobre ellos y la amplitud de su base de instalación.
Entonces me preguntaba si instalo git 1.9 primero [...] y hago las "Herramientas de desarrollo" de yum groupinstall, esto resultaría en problemas de conflicto de algún tipo.
Potencialmente, sólo hay que ver qué hace. En última instancia, depende del mantenedor del repositorio asegurarse de que las personas que usan sus repositorios tengan el viaje más fluido posible, por lo que es difícil saber qué obtendrá una vez que se aleje de los repositorios más conocidos.
Primero agregaría las herramientas de desarrollo --disablerepo=repoNamepara que se instale y solo espero que el mantenedor del repositorio lo use como punto de referencia al decidir cómo construir estos RPM. Eso parece ser lo que tendría más posibilidades de éxito. A groupinstallincluirá más paquetes (directamente y para dependencias) que instalar una aplicación en particular desde voluntad. Entonces, si algo del canal base entra en conflicto con el RPM del repositorio no oficial, debería ser más fácil fragmentarlo y eliminar los paquetes del canal base.
Estoy tratando de ser muy cauteloso aquí porque es el servidor que usará todo el equipo y no tengo la opción de crear una instantánea para retroceder en caso de que suceda algo...
Si ese es el caso, revisaría cuidadosamente la lista de actualizaciones con cada actualización y me aseguraría de que provengan de los repositorios correctos antes de indicarle que continúe con la instalación.