현재 안정node.js버전은v0.12.2. 방금 내 yum update컴퓨터에서 실행했는데 노드가 다음과 같이 업데이트되었습니다.v0.10.36.
내 EPEL 저장소 버전이 현재 안정적인 버전에 비해 너무 오래된 이유는 무엇입니까? yum을 통해 노드를 최신 버전으로 업데이트할 수 있나요? 아니면 직접 컴파일해야 하나요?
CentOS 6.6이 있습니다
답변1
RHEL 6은 이전출시된2010년에 그리고 선택한 결과 중 하나는기업장기적인 지원 주기로 배포하면 소프트웨어의 오래된 버전처럼 보이고 안정성과 타사 소프트웨어에 대한 더 나은 지원을 절충하게 됩니다.
(메모:이전 버전은 안전하지 않다는 뜻이 아닙니다. 다음 내용을 읽어보세요.백포팅보안 업데이트.)
일반적으로 최신 버전이 필요한 경우 다음 주요 릴리스, 즉 RHEL 7을 찾아야 합니다.
다음을 구독하면 이전 Red Hat Enterprise Linux 릴리스에서 특정 소프트웨어의 최신 지원 버전을 얻을 수 있습니다. 소프트웨어 컬렉션채널.
Node.js는 현재 릴리스 0.10으로 지원되는 SC 채널의 일부이므로 맞는 것 같습니다.
답변2
EPEL에 최신 버전이 포함되어 있지 않은 이유에 대해서는EPEL 지침 및 정책:
Fedora Extras와 같은 최신 패키지가 포함된 롤링 릴리스는 어떻습니까?
왜 그래야 할까요? 이것이 바로 Fedora Extras가 수행하고 작동하고 잘 작동하는 일입니다. 하지만 이는 주로 Fedora(Core)가 많은 업데이트와 거의 롤링 릴리스 방식/빠른 릴리스 주기를 갖추고 있기 때문입니다. 그러나 우리가 구축한 Enterprise Linux는 업데이트에 훨씬 더 주의를 기울이고 수명 주기가 더 깁니다. 따라서 우리는 EPEL에 대해서도 동일한 작업을 수행해야 합니다. 대부분의 사용자는 어떤 이유로 안정적인 배포판을 선택했기 때문에 그런 방식을 선호할 것입니다. 최신 패키지를 원한다면 Fedora를 선택했을 수 있습니다.
물론, 안정적인 기반과 그 위에 새로운 패키지 세트가 혼합되어 있는 것이 필요한 영역이 많이 있습니다.아마도EPEL 프로젝트는 장기적으로 그러한 경우에 대한 솔루션(신중하게 업데이트된 저장소와 병행하여!)을 제공하지만 시작을 위한 솔루션은 제공하지 않습니다. 이미 이 방향으로 무언가를 제공하는 제3자 저장소가 있으므로 사용자는 이미 해당 저장소의 서비스를 받고 있을 수도 있습니다.
추가: Fedora Extras와 같은 롤링 릴리스 방식은 다른 이유로 많은 EPEL 패키지에서 불가능합니다. 새 패키지에는 종종 특정 핵심 라이브러리의 새 버전이 필요합니다. 이는 핵심 OS의 라이브러리를 대체하므로 업데이트된 라이브러리를 제공할 수 없기 때문에 EPEL에 문제를 일으킬 것입니다.
예: 이 문서는 RHEL5가 출시되었을 때 작성되었습니다. RHEL5용으로 빌드된 많은 패키지는 이미 이 시점에서 RHEL4용으로 빌드할 수 없습니다. RHEL4-gtk2-Package는 2년이 되었고 최신 gtk2에 의존하기 때문에 많은 현재 애플리케이션에 비해 너무 오래되었기 때문입니다. 따라서 아주 새로운 패키지로 롤링 방식을 시도하더라도 libs에 대한 종속성으로 인해 많은 패키지를 빌드할 수 없기 때문에 실패하게 됩니다. 결국 우리는 아주 새로운 패키지가 포함된 저장소를 가지게 될 것이고 다른 패키지는 여전히 꽤 오래된 것입니다. 이러한 혼합은 "최신 버전" 또는 "신중한 업데이트만" 측면을 만족시키지 못할 것입니다. 그래서 우리는 "신중한 업데이트만" 측면을 목표로 삼으려고 합니다. EPEL의 지원 및 업데이트 주기는 Fedora보다 훨씬 길다는 점을 기억하십시오.