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
이것이 어떤 식으로든 시스템을 중단시키거나 불안정하게 만들까요?
특정 저장소에서만 사용할 수 있는 소프트웨어가 필요하다면 아마도 그것을 선택할 것입니다. 먼저 실제로 필요한지 확인하십시오.
repo/rpm이 잘못 설계되면 문제가 발생합니다. 이로 yum인해 동일한 이름을 가진 다른 리포지토리에서 사용할 수 있기 때문에 특정 패키지의 최신 버전이 설치되지만 기본 채널의 일부 소프트웨어는 이전 버전 번호에 대해 구축되었기 때문에 더 이상 설치되지 않는 상황이 발생할 수 있습니다 . 이로 인해 직관적으로 해결하거나 종료할 수 없는 클러스터링 문제가 발생할 수 있습니다.
enabled=0EPEL 이외의 다른 것을 사용하는 경우 일반적으로 비활성화되도록 저장소를 구성 하지만 필요한 경우 그렇게 말할 수 있습니다 yum install packageName --enablerepo=repoName. 이렇게 하면 이 저장소의 일부 콘텐츠가 실수로 설치되는 것을 방지할 수 있습니다.
물론, 기본 채널 팩이 품질 검사와 설치 기반의 폭 때문에 최신 및 최고의 채널 팩보다 분명히 더 안정적이라는 문제도 있습니다.
그래서 git 1.9를 먼저 설치하고 [...] yum groupinstall "Development Tools"를 수행하면 일종의 충돌 문제가 발생할지 궁금합니다.
그것은 가능합니다. 당신은 그것이 무엇을 하는지 보기만 하면 됩니다. 궁극적으로 리포지토리 관리자는 자신의 리포지토리를 사용하는 사람들이 가능한 한 원활하게 사용할 수 있도록 해야 하므로 잘 알려진 리포지토리에서 벗어나면 무엇을 얻게 될지 알기가 어렵습니다.
먼저 --disablerepo=repoName쉬운 설치를 위해 개발 도구에 하나를 추가하고 저장소 관리자가 이러한 RPM을 구축하는 방법을 결정할 때 이를 참조 지점으로 사용하기를 바랍니다. 이것이 성공할 가능성이 가장 높은 것 같았습니다. A에는 groupinstall특정 응용 프로그램에서 설치되는 것보다 더 많은 패키지(직접 및 종속성)가 포함됩니다. 따라서 기본 채널의 항목이 비공식 저장소의 RPM과 충돌하는 경우 이를 분해하고 기본 채널 패키지를 제거하는 것이 더 쉬울 것입니다.
팀 전체가 사용할 서버이고 문제가 발생할 경우를 대비해 롤백할 스냅샷을 생성할 수 있는 옵션이 없기 때문에 매우 조심하려고 합니다...
그렇다면 각 업데이트에 대한 업데이트 목록을 살펴보고 설치를 계속하라고 지시하기 전에 해당 업데이트가 올바른 저장소에서 왔는지 확인합니다.