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