Estable actualnodo.jsla versión esv0.12.2. Acabo de ejecutar yum updateen mi máquina y actualizó el nodo av0.10.36.
¿Por qué la versión de mi repositorio de EPEL es tan antigua en comparación con la versión estable actual? ¿Puedo actualizar el nodo a la última versión a través de yum o tengo que compilarlo yo mismo?
tengo centos 6.6
Respuesta1
RHEL 6 fueliberadoen 2010 y una de las consecuencias de elegir unempresadistribución con ciclos de soporte a largo plazo es que terminará con versiones aparentemente antiguas de software, una compensación por la estabilidad y un mejor soporte para software de terceros.
(Nota:una versión antigua no equivale a insegura, lea másrespaldode actualizaciones de seguridad.)
Normalmente, si necesita algo más reciente, debe buscar la próxima versión principal, es decir, RHEL 7.
Es posible obtener versiones compatibles más recientes de cierto software en versiones anteriores de Red Hat Enterprise Linux suscribiéndose al Colecciones de softwarecanal.
Node.js es parte del canal SC actualmente compatible con la versión 0.10, por lo que parece correcto.
Respuesta2
Respecto a por qué EPEL no contiene las últimas versiones, tomado delDirectrices y políticas de EPEL:
¿Por qué no una versión continua con los paquetes más recientes como los que había en Fedora Extras?
¿Por qué deberíamos? Eso sería lo que Fedora Extras hizo y funcionó y funciona bien, pero eso se debe principalmente a que Fedora (Core) tiene muchas actualizaciones y también un esquema de lanzamiento casi continuo/ciclo de lanzamiento rápido. Pero el Enterprise Linux con el que construimos es mucho más cuidadoso con las actualizaciones y tiene un ciclo de vida más largo; por lo tanto, deberíamos hacer lo mismo con EPEL, ya que la mayoría de los usuarios lo preferirán así, ya que eligieron una distribución estable por algunas razones: si quieren los paquetes más recientes, podrían haber elegido Fedora.
Claro, hay muchas áreas en las que se desea tener una combinación de una base estable y un conjunto de paquetes bastante nuevos encima.Tal vezEl proyecto EPEL proporcionará una solución (¡en paralelo al repositorio cuidadosamente actualizado!) para esos casos a largo plazo, pero no al principio. Ya existen repositorios de terceros que proporcionan algo en esta dirección, por lo que es posible que los usuarios ya los utilicen.
Además: un esquema de lanzamiento continuo como lo hizo Fedora Extras no es posible para muchos paquetes EPEL por otra razón: los nuevos paquetes a menudo requieren nuevas versiones de ciertas bibliotecas principales. Esto causará problemas en EPEL porque no podremos proporcionar bibliotecas actualizadas, ya que reemplazarían las bibliotecas en el sistema operativo principal.
Ejemplo: este documento se escribió aproximadamente cuando se lanzó RHEL5; Muchos paquetes que se compilan para RHEL5 no se pueden compilar para RHEL4 en este momento, ya que el paquete RHEL4-gtk2 tiene dos años y es demasiado antiguo para muchas aplicaciones actuales, ya que dependen de un gtk2 más nuevo. Entonces, incluso si intentáramos tener un esquema continuo con un paquete bastante nuevo, fracasaríamos, ya que no podemos construir un montón de paquetes debido a estas dependencias en las bibliotecas; al final tendríamos un repositorio con algunos paquetes bastante nuevos mientras que otros aún son bastante antiguos. Esa combinación no haría felices a ninguna de las partes de las "últimas versiones" o de las "actualizaciones cuidadosas"; por eso tratamos de apuntar a los lados que "solo actualizan cuidadosamente". Recuerde, el ciclo de soporte y actualizaciones de EPEL es mucho más largo que el de Fedora.