versão nodejs no repositório EPEL

Question

A versão atual do node.js está v0.12.2 . Acabei de executar yum update na minha máquina e atualizei o nó para v0.10.36 .

Por que minha versão do repo EPEL é tão antiga em comparação com a versão estável atual? Posso atualizar o nó para a versão mais recente através do yum ou tenho que compilá-lo sozinho?

Eu tenho o CentOS 6.6

    

Answer 1

O RHEL 6 foi lançado em 2010 e uma das consequências da escolha de uma distribuição empresarial Com ciclos de suporte de longo prazo, você terá versões antigas de software, um compromisso de estabilidade e melhor suporte para softwares de terceiros.

( Nota: uma versão antiga não equivale a insegura, leia em backporting de atualizações de segurança.

Normalmente, se você precisar de algo mais recente, procure a próxima versão importante, ou seja, o RHEL 7.

Você pode obter versões suportadas mais recentes de certos softwares em versões anteriores do Red Hat Enterprise Linux assinando o Canal de coleções de software .

O Node.js faz parte do canal SC atualmente suportado como release 0.10, o que parece correto.

    

Answer 2

Sobre o motivo pelo qual o EPEL não contém as versões mais recentes, tiradas da Diretrizes e políticas do EPEL :

Why not a rolling release with latest packages like what was in Fedora Extras?

Why should we? That would be what Fedora Extras did and worked and works well for it -- but that's mainly because Fedora (Core) has lots of updates and a nearly rolling-release scheme/quick release cycle, too. But the Enterprise Linux we build against is much more careful with updates and has longer life-cycle; thus we should do the same for EPEL, as most users will properly prefer it that way, as they chose a stable distro for some reasons -- if they want the latest packages they might have chosen Fedora.

Sure, there are lots of areas where having a mix of a stable base and a set of quite new packages on top of it is wanted. Maybe the EPEL project will provide a solution (in parallel to the carefully updated repository!) for those cases in the long term, but not for the start. There are already third party repositories out there that provide something in this direction, so users might be served by them already.

Further: A rolling release scheme like Fedora Extras did is not possible for many EPEL packages for another reason, new packages often require new versions of certain core libraries. This will cause problems in EPEL because we won't be able to provide updated libs as it would replace libraries in the core OS.

Example: This document was written round about when RHEL5 got released; many packages that get build for RHEL5 can't be build for RHEL4 at this point of time already, as the RHEL4-gtk2-Package is two years old and is too old for many current applications, as they depend on a newer gtk2. So if even if we would try to have a rolling scheme with quite new package we'd fail, as we can't build a bunch of package due to this dependencies on libs; in the end we would have a repo with some quite new packages while others are still quite old. That mix wouldn't make either of the "latest versions" or "careful updates only" sides happy; so we try to target the "careful updates only" sides. Remember, EPEL's support and updates cycle is much longer then Fedora's.