EPELリポジトリのnodejsバージョン
現在の安定版 node.js バージョンはv0.12.2です。マシンでyum updateを実行すると、ノードがv0.10.36に更新されました。
私のEPELリポジトリバージョンが現在の安定したバージョンと比べてとても古いのはなぜですか？ yumを介してノードを最新バージョンに更新できますか、それとも自分でコンパイルする必要がありますか？
CentOS6.6を持っています
RHEL 6は2010年に リリース でした。長期サポートサイクルを備えたエンタープライズディストリビューションを選択した結果の1つは、最終的には古いバージョンのソフトウェアのように見え、安定性とサードパーティソフトウェアのサポートの向上とのトレードオフになります。
（注：古いバージョンは安全ではありません。 backporting セキュリティアップデートの。）
通常、より新しいものが必要な場合は、次のメジャーリリース（RHEL 7）を探す必要があります。
Software Collections チャネルにサブスクライブすることで、古いRed Hat EnterpriseLinuxリリースでサポートされている特定のソフトウェアの最新バージョンを入手できる場合があります。
Node.jsは、リリース0.10として現在サポートされているSCチャネルの一部であるため、ほぼ正しいようです。
EPELに最新バージョンが含まれていない理由について EPELガイドラインとポリシー ：
Fedora Extrasにあったような最新のパッケージを含むローリングリリースはどうですか？
なぜ私たちがすべきですか？これは、Fedora Extrasが実行し、機能し、うまく機能することです。ただし、これは主に、Fedora（Core）に多くの更新があり、ほぼローリングリリーススキーム/クイックリリースサイクルもあるためです。しかし、私たちが構築するEnterprise Linuxは、更新にはるかに注意を払い、ライフサイクルが長くなっています。したがって、EPELについても同じことを行う必要があります。ほとんどのユーザーは、何らかの理由で安定したディストリビューションを選択したため、その方法を適切に好むでしょう。最新のパッケージが必要な場合は、Fedoraを選択した可能性があります。
確かに、安定したベースとその上にまったく新しいパッケージのセットを組み合わせることが望まれる分野はたくさんあります。 たぶんEPELプロジェクトは、長期的にはこれらのケースに対して（慎重に更新されたリポジトリと並行して！）ソリューションを提供しますが、最初は提供しません。この方向に何かを提供するサードパーティのリポジトリがすでに存在するため、ユーザーはすでにそれらのリポジトリからサービスを受けている可能性があります。
さらに：Fedora Extrasのようなローリングリリーススキームは、別の理由で多くのEPELパッケージでは不可能でした。新しいパッケージでは、特定のコアライブラリの新しいバージョンが必要になることがよくあります。これにより、EPELで問題が発生します。これは、コアOSのライブラリを置き換えるため、更新されたライブラリを提供できないためです。
例：このドキュメントは、RHEL5がリリースされた頃に書かれました。 RHEL4-gtk2-Packageは2年前であり、新しいgtk2に依存しているため、現在の多くのアプリケーションには古すぎるため、RHEL5用にビルドされる多くのパッケージは現時点ではRHEL4用にビルドできません。したがって、まったく新しいパッケージを使用してローリングスキームを作成しようとしても、このライブラリへの依存関係のために多数のパッケージを構築できないため、失敗します。結局、いくつかの非常に新しいパッケージを含むリポジトリがありますが、他のパッケージはまだかなり古いものです。その組み合わせは、「最新バージョン」または「注意深い更新のみ」のどちらの側も満足させるものではありません。そのため、「注意深い更新のみ」の側面をターゲットにしようとしています。 EPELのサポートと更新のサイクルはFedoraよりもはるかに長いことを忘れないでください。