CentOS 타사 리포지토리로 작업할 때 많은 두려움, 불확실성 및 의심이 있습니다. 이것은 에서 나온 구절이다.CentOS 저장소 페이지특히 EPEL에 관해:
EPEL(Enterprise Linux)용 추가 패키지 - (참조http://fedoraproject.org/wiki/EPEL)는 EL6 및 EL7용 Fedora 패키지 재구축을 제공합니다. 콤보해서는 안 된다포인트 릴리스와 관련된 과거 문제에도 불구하고 교체 베이스. yum --enablerepo=extras install epel-release를 실행하여 EPEL을 설치할 수 있습니다. epel-release 패키지는 기본적으로 활성화된 CentOS Extras 저장소에 포함되어 있습니다. 지원은 Freenode, 메일링 리스트 및 #epel의 이슈 추적기를 통해 제공됩니다. EPEL 업데이트가 안정 릴리스로 푸시되기 전에 테스트하는 데 도움을 주고 싶다면 개발/테스트 서버에서 epel-testing 저장소를 활성화할 수 있습니다. 프로덕션 시스템에서 epel 테스트를 활성화하는 것은 좋은 생각이 아닙니다.
나도 이 문장에 대해 같은 생각을 갖고 있다"해서는 안 된다". CentOS 문서에 "EPEL을 사용하면 모든 것이 괜찮을 것입니다. 하지만 특히 포인트 게시의 경우 정말 나쁜 일도 발생할 수 있다는 것을 누가 알겠습니까?"라고 말하는 것과 거의 같습니다.
이전 섹션의 내용입니다.CentOS 저장소 페이지문제가 요약되고 해결 방법에 대한 세 가지 권장 사항이 제시됩니다.
참고: 타사 저장소 사용을 고려하고 있다면 이러한 보조 아카이브의 실수로 "업데이트"가 CentOS의 특정 핵심 부분을 덮어쓰는 것을 방지하는 방법을 진지하게 고려해야 합니다. 한 가지 접근 방식은 이러한 아카이브를 가끔씩만 활성화하고 일반적으로 비활성화하는 것입니다. 참조: 만냠
대안은 /etc/yum.repos.d/에 있는 일치하는 .conf 파일에서 하위 아카이브별로 Except= 및 includepkgs= 옵션을 사용하는 것입니다. man yum.conf를 참조하세요.
yum Priorities 플러그인은 타사 저장소가 기본 패키지를 대체하거나 기본/업데이트가 타사 패키지를 대체하는 것을 방지할 수 있습니다.
첫 번째 제안은 기본적으로 EPEL 및 기타 타사 저장소를 비활성화한 후 다음과 같은 방법을 사용하여 패키지를 설치하는 것입니다.
[user@hostname ~]$ sudo dnf --enablerepo=epel install p7zip
위 내용은 CentOS의 일부 핵심 부분을 덮어쓰지 않는다는 것을 보장합니까(문서에서는 이 문제가 다음과 관련되어 있음을 모호하게 암시합니다).고쳐 쓰다반드시 패키지를 설치할 필요는 없습니다)? 그렇다면 여전히 도움이 됩니까? 타사 저장소에서 패키지를 업데이트해야 하면 어떻게 되나요?
두 번째 제안은 "/etc/yum.repos.d/에 있는 일치하는 .conf 파일에서 하위 아카이브별로 Except= 및 includepkgs= 옵션을 사용"하는 것입니다. 제외하거나 포함해야 하는 패키지와 시기를 어떻게 알 수 있나요? 이 조언은 타사 저장소에서 패키지를 설치하기 전에 패키지를 주의 깊게 연구해야 한다는 의미입니까? 나는 yum
및 의 모든 내용을 아는 것에 반대하지는 않지만 dnf
새로운 사용자가 이 접근 방식에 익숙해질 수 있도록 기본적이고 유용한 전략을 갖는 것은 매우 유용할 것입니다.
세 번째 제안은 이 플러그인을 사용하는 것인데 Priorities
, 실제로 CentOS 8의 DNF에 내장되어 있는 것으로 알고 있습니다.우선순위 페이지매우 충격적인 면책 조항이 있습니다.
참고: yum의 업스트림 관리자인 Seth Vidal은 2009년 9월 "yum 우선순위"에 대해 다음과 같이 말했습니다.
맙소사, 사람들이 냠냠의 우선순위를 정하지 않았으면 좋겠어요. 나를 오그라들게 만드는 우선순위에 관한 것들이 너무 많습니다. 어쩌면 던지고 싶게 만드는 적절한 "세트"가 생각나서일 수도 있습니다.
이 특별한 것페이지"[CentOS] yum-priorities에 무슨 문제가 있나요?"라는 스레드에서 나는 많은 우려를 갖고 있습니다.
RP Herrold는 다음과 같이 썼습니다. > "Priority"는
이 시점에서 자체 유도된 종속성 지옥으로 인해 무너지고 죽고, CentOS는 > 뒷면의 튄 자국 때문에 비난을 받습니다. 저는 위키 문서 편집자이고 원래 우선순위를 보고 "최상의" 대안으로 밀려난 후에 해당 경고 섹션을 추가했습니다. >> 그렇지 않습니다. 러시안 룰렛에 가깝습니다. 방의 상태를 보지 않고도 설치할 수 있습니다. > 언급된 "exclude" 및 "includepkg" 방법이 더 정확하지만 > yum 및 rpm 매뉴얼 페이지를 읽고 > 종속성을 어느 정도 이해해야 합니다.그리고단일 네임스페이스 및 파일 트리에서 서로 다른 당사자가 조정하지 않은 향후 변경 사항을 예측하기 위한 수정구슬입니다. 이 문제를 해결하는 유일한 방법은 정책이 아무것도 제외하지 않고 이름과 파일이 조정되는 단일 저장소를 갖거나, 충돌을 방지하기 위해 패키지와 파일 네임스페이스를 조정할 수 없는 저장소에 위임하는 것입니다. 두 시나리오 모두 가능성이 낮아 보입니다.
——레스
맥셀
"수정구슬"이 정말 필요한가요, 아니면 단지 두려움을 불러일으키는 것인가요? 내가 어떻게 할 수있는보장하다CentOS의 핵심 부분은 타사 리포지토리에서 다루지 않지만 이러한 리포지토리(특히 EPEL)에서 제공하는 패키지를 계속 사용할 수 있습니까? 타사 리포지토리에서 패키지를 안전하게 설치하고 업데이트하는 방법은 무엇입니까? CentOS의 핵심 부분이 언제 다루어지는지 적어도 분명합니까?