現在の安定ノードバージョンはv0.12.2.yum updateマシンで実行したところ、ノードが更新されましたバージョン0.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 プロジェクトは、長期的にはこれらのケースに対するソリューション (慎重に更新されたリポジトリと並行して!) を提供しますが、最初はそうではありません。この方向で何かを提供するサードパーティのリポジトリはすでに存在するため、ユーザーはすでにそれらによってサービスを提供されている可能性があります。
さらに、Fedora Extras のようなローリング リリース スキームは、別の理由により、多くの EPEL パッケージでは不可能です。新しいパッケージでは、特定のコア ライブラリの新しいバージョンが必要になることがよくあります。これにより、コア OS のライブラリが置き換えられるため、更新されたライブラリを提供できなくなるため、EPEL で問題が発生します。
例: このドキュメントは、RHEL5 がリリースされた頃に書かれました。RHEL5 用にビルドされる多くのパッケージは、この時点では RHEL4 用にビルドできません。RHEL4-gtk2-Package は 2 年前のものであり、新しい gtk2 に依存する多くの現在のアプリケーションには古すぎるためです。そのため、たとえ非常に新しいパッケージでローリング スキームを試みても、ライブラリへの依存関係のために多くのパッケージをビルドできないため失敗します。最終的には、非常に新しいパッケージとまだかなり古いパッケージが混在するリポジトリが作成されます。この組み合わせは、「最新バージョン」側と「慎重に更新するだけ」側のどちらにも満足させません。そのため、私たちは「慎重に更新するだけ」側をターゲットにしようとします。EPEL のサポートと更新サイクルは Fedora よりもはるかに長いことに注意してください。