나는 RedHat에 비공식 저장소를 설치하는 것이 좋은 생각이 아니라는 것을 읽었습니다. 그래서 설치하려고 했는데NodeJSRH 서버에서 git 버전이 1.7.1인 것을 확인했습니다. 우리 팀은 로컬 우분투에서 1.9를 사용하고 있습니다. 그래서 설치할까 고민하다가자식 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동일한 이름으로 다른 저장소에서 사용할 수 있기 때문에 특정 패키지의 더 높은 버전을 설치하지만 기본 채널의 일부 소프트웨어는 이전 버전 번호에 대해 구축되었기 때문에 더 이상 설치되지 않는 상황으로 이어질 수 있습니다 . 이는 일반적으로 직관적으로 해결되지 않거나 취소되지 않는 문제의 클러스터 프랙을 생성할 수 있습니다.
enabled=0EPEL 이외의 다른 것을 사용하는 경우 저장소가 일반적으로 비활성화되도록 저장소를 구성 하지만 필요한 경우 이라고 말할 수 있습니다 yum install packageName --enablerepo=repoName. 이렇게 하면 해당 저장소의 항목이 실수로 설치되는 것을 방지할 수 있습니다.
물론, 기본 채널 패키지가 QA와 설치 기반의 폭 때문에 최신 및 최고의 패키지보다 정의적으로 더 안정적이라는 문제도 있습니다.
그래서 git 1.9를 먼저 설치하고 [...] yum groupinstall "Development Tools"를 수행하면 일종의 충돌 문제가 발생하는지 궁금합니다.
잠재적으로, 당신은 그것이 무엇을 하는지를 봐야만 합니다. 궁극적으로 리포지토리를 사용하는 사람들이 가능한 한 가장 원활하게 이동할 수 있도록 하는 것은 리포지토리 관리자에게 달려 있으므로 더 잘 알려진 리포지토리에서 벗어나면 무엇을 얻게 될지 말하기는 어렵습니다.
나는 개발 도구를 먼저 추가하여 --disablerepo=repoName설치되도록 하고 저장소 관리자가 이러한 RPM을 구축하는 방법을 결정할 때 이를 참조 지점으로 사용하기를 바랍니다. 성공할 가능성이 가장 높은 것 같습니다. A groupinstall에는 will에서 특정 애플리케이션을 설치하는 것보다 더 많은 패키지(직접 및 종속성을 위한)가 포함됩니다. 따라서 기본 채널의 내용이 비공식 저장소의 RPM과 충돌하는 경우 이를 단편적으로 처리하고 기본 채널 패키지를 제거하는 것이 더 쉬울 것입니다.
여기서는 팀 전체가 사용할 서버이고, 무슨 일이 일어날 경우를 대비해 롤백하기 위해 스냅샷을 생성하는 옵션이 없기 때문에 매우 조심하려고 합니다...
그렇다면 각 업데이트의 업데이트 목록을 주의 깊게 살펴보고 설치를 계속 진행하기 전에 해당 업데이트가 올바른 저장소에서 왔는지 확인합니다.