Eu estava lendo que instalar repositórios não oficiais no RedHat não era uma boa ideia. Então eu estava tentando instalarNodeJSno RH Server e vi que a versão do git era 1.7.1. Nossa equipe está usando 1.9 em seu Ubuntu local. Então eu queria saber se eu instalopeguei 1,9primeiro (isso quebraria/tornaria o sistema instável de alguma forma? - também preciso disso porque preciso configurar o servidor git posteriormente) e isso yum groupinstall "Development Tools"
resultaria em algum tipo de problema de conflito?
Estou tentando ser muito cauteloso aqui porque é o servidor que toda a equipe usará e não tenho a opção de criar um snapshot para reverter caso algo aconteça...
==========================================================================================================
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)
Responder1
isso quebraria/tornaria o sistema instável de alguma forma?
Se você precisar de um software que esteja disponível apenas em um determinado repositório, provavelmente eu o usaria. Apenas certifique-se de que você realmente precisa dele primeiro.
Os problemas surgem quando os repositórios/rpms são mal projetados. Isso pode levar a situações em que yumserá instalada uma versão superior de um pacote específico porque está disponível em outro repositório com o mesmo nome, mas algum software do canal base não será mais instalado porque foi compilado em um número de versão anterior. Isso pode criar um clusterfrack de um problema que geralmente não é resolvido intuitivamente ou do qual não é possível recuperá-lo.
Se você usar algo diferente de EPEL, eu apenas configuraria o repositório com enabled=0para que o repositório seja desabilitado em geral, mas se precisar, basta dizer yum install packageName --enablerepo=repoName. Isso evita que algo desse repositório seja instalado acidentalmente.
Claro, há também o problema de que os pacotes de canais básicos são definitivamente mais estáveis do que os melhores e mais recentes apenas por causa do controle de qualidade feito neles e da amplitude de sua base instalada.
Então, eu queria saber se eu instalar o git 1.9 primeiro [...] e fazer o yum groupinstall "Ferramentas de Desenvolvimento" resultaria em algum tipo de problema de conflito.
Potencialmente, você apenas precisa ver o que ele faz. Em última análise, cabe ao mantenedor do repositório garantir que as pessoas que usam seus repositórios tenham a jornada mais tranquila possível, por isso é difícil dizer o que você obterá quando se afastar dos repositórios mais conhecidos.
Eu faria as ferramentas de desenvolvimento primeiro adicionando um --disablerepo=repoNamea ele para que fosse instalado e só espero que o mantenedor do repositório use isso como ponto de referência ao decidir como construir esses RPMs. Essa parece ser a coisa que teria a melhor chance de sucesso. A groupinstallincluirá mais pacotes (diretamente e para dependências) do que instalar um aplicativo específico por vontade própria. Portanto, se algo do canal base entrar em conflito com o RPM do repositório não oficial, será mais fácil fragmentá-lo e remover os pacotes do canal base.
Estou tentando ser muito cauteloso aqui porque é o servidor que toda a equipe usará e não tenho a opção de criar um snapshot para reverter caso algo aconteça...
Se for esse o caso, eu examinaria cuidadosamente a lista de atualizações com cada atualização e me certificaria de que elas vêm dos repositórios corretos antes de solicitar que prossiga com a instalação.