Atual estávelnó.jsa versão év0.12.2. Acabei de executar yum updatena minha máquina e atualizei o nó parav0.10.36.
Por que minha versão do repositório 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 preciso compilá-lo sozinho?
Eu tenho CentOS 6.6
Responder1
RHEL 6 eralançadoem 2010 e uma das consequências da escolha de umempreendimentodistribuição com ciclos de suporte de longo prazo é que você acabará com versões aparentemente antigas de software, uma compensação pela estabilidade e melhor suporte para software de terceiros.
(Observação:uma versão antiga não significa insegura, leia embackportde atualizações de segurança.)
Normalmente, se você precisar de algo mais recente, você deve procurar a próxima versão principal, ou seja, RHEL 7.
Você pode obter versões suportadas mais recentes de determinados softwares em versões mais antigas do Red Hat Enterprise Linux assinando o Coleções de softwarecanal.
Node.js faz parte do canal SC atualmente suportado na versão 0.10, então isso parece correto.
Responder2
Quanto ao motivo pelo qual EPEL não contém as versões mais recentes, retiradas doDiretrizes e Políticas da EPEL:
Por que não um lançamento contínuo com os pacotes mais recentes, como o que estava no Fedora Extras?
Por que deveríamos? Isso seria o que o Fedora Extras fez e funcionou e funciona bem - mas isso ocorre principalmente porque o Fedora (Core) tem muitas atualizações e um esquema de lançamento quase contínuo/ciclo de lançamento rápido também. Mas o Enterprise Linux no qual construímos é muito mais cuidadoso com atualizações e tem um ciclo de vida mais longo; portanto, devemos fazer o mesmo com o EPEL, já que a maioria dos usuários preferirá assim, já que escolheram uma distro estável por alguns motivos - se quiserem os pacotes mais recentes, podem ter escolhido o Fedora.
Claro, há muitas áreas onde é necessário ter uma combinação de uma base estável e um conjunto de pacotes bastante novos.Talvezo projeto EPEL fornecerá uma solução (em paralelo ao repositório cuidadosamente atualizado!) para esses casos a longo prazo, mas não para o início. Já existem repositórios de terceiros que fornecem algo nesse sentido, então os usuários já podem ser atendidos por eles.
Além disso: um esquema de lançamento contínuo como o Fedora Extras fez não é possível para muitos pacotes EPEL por outro motivo: novos pacotes geralmente requerem novas versões de certas bibliotecas principais. Isso causará problemas no EPEL porque não poderemos fornecer bibliotecas atualizadas, pois isso substituiria as bibliotecas no sistema operacional principal.
Exemplo: Este documento foi escrito por volta da época em que o RHEL5 foi lançado; muitos pacotes que são compilados para RHEL5 não podem ser compilados para RHEL4 neste momento, pois o RHEL4-gtk2-Package tem dois anos e é muito antigo para muitos aplicativos atuais, pois dependem de um gtk2 mais recente. Então, mesmo que tentássemos ter um esquema contínuo com pacotes bastante novos, falharíamos, pois não podemos construir um monte de pacotes devido a essas dependências de libs; no final teríamos um repositório com alguns pacotes bastante novos enquanto outros ainda são bastante antigos. Essa mistura não deixaria nenhum dos lados das “versões mais recentes” ou “somente atualizações cuidadosas” felizes; por isso, tentamos atingir os lados "somente atualizações cuidadosas". Lembre-se, o ciclo de suporte e atualizações do EPEL é muito mais longo que o do Fedora.