Текущая стабильная node.js версия v0.12.2. Я просто бегу yum update на моей машине, и он обновил узел до Версия 0.10.36.
Почему моя репо-версия EPEL такая старая по сравнению с текущей стабильной? Могу ли я обновить node до последней версии через yum или мне придется компилировать его самостоятельно?
У меня CentOS 6.6
RHEL 6 был выпущенный в 2010 году и одно из последствий выбора предприятие Распространение с долгосрочными циклами поддержки, вы в конечном итоге получите кажущиеся старые версии программного обеспечения, компромисс для стабильности и лучшей поддержки стороннего программного обеспечения.
(Примечание: старая версия не означает небезопасность, читайте дальше резервное копирование обновлений безопасности.)
Обычно, если вам нужно что-то более свежее, вам следует искать следующий основной выпуск, то есть RHEL 7.
Вы можете получить более свежие поддерживаемые версии определенного программного обеспечения в старых выпусках Red Hat Enterprise Linux, подписавшись на Коллекции программного обеспечения канал.
Node.js является частью канала SC, который в настоящее время поддерживается в версии 0.10, так что это кажется правильным.
Относительно того, почему EPEL не содержит последних версий, взятых из Руководящие принципы и политика EPEL:
Почему бы не выпустить скользящий выпуск с последними пакетами, как в Fedora Extras?
Зачем нам? Это было бы то, что Fedora Extras делала, работала и хорошо для нее работала - но это в основном потому, что Fedora (Core) имеет множество обновлений и почти непрерывную схему выпуска / цикл быстрого выпуска. Но Enterprise Linux, на котором мы строим, гораздо более осторожен с обновлениями и имеет более длительный жизненный цикл; таким образом, мы должны сделать то же самое для EPEL, поскольку большинство пользователей предпочтут именно так, поскольку они выбрали стабильный дистрибутив по некоторым причинам - если им нужны последние пакеты, они могли бы выбрать Fedora.
Конечно, есть много областей, в которых требуется сочетание стабильной базы и набора совершенно новых пакетов поверх нее. Может быть проект EPEL предоставит решение (параллельно с тщательно обновленным репозиторием!) для этих случаев в долгосрочной перспективе, но не для начала. Уже существуют сторонние репозитории, которые предоставляют что-то в этом направлении, поэтому они уже могут обслуживать пользователей.
Далее: схема скользящего выпуска, такая как Fedora Extras, невозможна для многих пакетов EPEL по другой причине: для новых пакетов часто требуются новые версии определенных основных библиотек. Это вызовет проблемы в EPEL, потому что мы не сможем предоставлять обновленные библиотеки, поскольку они заменят библиотеки в основной ОС.
Пример: этот документ был написан примерно в то время, когда был выпущен RHEL5; многие пакеты, которые собираются для RHEL5, уже не могут быть собраны для RHEL4 на данный момент, поскольку пакету RHEL4-gtk2 уже два года и он слишком старый для многих текущих приложений, поскольку они зависят от более нового gtk2. Так что, даже если мы попытаемся создать скользящую схему с совершенно новым пакетом, мы потерпим неудачу, так как мы не сможем собрать кучу пакетов из-за этих зависимостей от библиотек; в итоге у нас будет репо с некоторыми совершенно новыми пакетами, в то время как другие все еще довольно старые. Такое сочетание не порадовало бы ни сторонников «последних версий», ни «только осторожных обновлений»; поэтому мы стараемся ориентироваться на стороны, "только осторожные". Помните, что цикл поддержки и обновлений EPEL намного длиннее, чем у Fedora.