EPEL 儲存庫上的 Nodejs 版本

EPEL 儲存庫上的 Nodejs 版本

目前穩定節點.js版本是v0.12.2。我剛剛yum update在我的機器上運行並將節點更新為v0.10.36

為什麼我的 EPEL 儲存庫版本比目前的穩定版本這麼舊?我可以透過 yum 將 Node 更新到最新版本還是必須自己編譯?

我有 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(核心)也有很多更新和近乎滾動發布的方案/快速發布週期。但我們建構的 Enterprise Linux 在更新方面更加謹慎,生命週期更長;因此我們應該對EPEL 做同樣的事情,因為大多數用戶會更喜歡這種方式,因為他們出於某種原因選擇了一個穩定的發行版——如果他們想要最新的軟體包,他們可能會選擇Fedora。

當然,有很多領域需要混合使用穩定的基礎和一組全新的軟體包。或許EPEL 專案將為這些情況提供長期的解決方案(與仔細更新的儲存庫並行!),但不是一開始的解決方案。已經有第三方儲存庫在這方面提供了一些東西,因此用戶可能已經得到了它們的服務。

此外:對於許多 EPEL 軟體包來說,像 Fedora Extras 那樣的滾動發布方案是不可能的,因為另一個原因,新軟體包通常需要某些核心庫的新版本。這將導致 EPEL 出現問題,因為我們將無法提供更新的庫,因為它將取代核心作業系統中的庫。

範例:本文檔是在 RHEL5 發佈時編寫的;目前,許多為 RHEL5 構建的軟體包無法為 RHEL4 構建,因為 RHEL4-gtk2-Package 已有兩年曆史,對於許多當前應用程式來說太舊了,因為它們依賴於較新的 gtk2。因此,即使我們嘗試使用相當新的套件進行滾動方案,我們也會失敗,因為由於對庫的依賴,我們無法建立一堆套件;最後,我們將擁有一個包含一些相當新的軟體包的儲存庫,而其他軟體包仍然很舊。這種混合不會讓「最新版本」或「僅仔細更新」雙方感到高興;所以我們嘗試針對「僅謹慎更新」方面。請記住,EPEL 的支援和更新周期比 Fedora 長得多。

相關內容