Aktueller Stallnode.jsVersion istVersion 0.12.2. Ich habe es gerade yum updateauf meiner Maschine ausgeführt und es hat den Knoten aktualisiert aufVersion 0.10.36.
Warum ist meine EPEL-Repo-Version im Vergleich zur aktuellen stabilen Version so alt? Kann ich Node über Yum auf die neueste Version aktualisieren oder muss ich es selbst kompilieren?
Ich habe CentOS 6.6
Antwort1
RHEL 6 warfreigegebenim Jahr 2010 und eine der Konsequenzen der Wahl einesUnternehmenBei einer Distribution mit langfristigen Support-Zyklen erhalten Sie am Ende scheinbar veraltete Softwareversionen, was ein Kompromiss zu Lasten der Stabilität und besseren Supports für Drittanbieter-Software ist.
(Notiz:Eine alte Version bedeutet nicht automatisch unsicher, informieren Sie sich überRückportierungvon Sicherheitsupdates.)
Wenn Sie etwas Neueres benötigen, sollten Sie normalerweise nach der nächsten Hauptversion suchen, z. B. RHEL 7.
Sie erhalten möglicherweise neuere unterstützte Versionen bestimmter Software in älteren Red Hat Enterprise Linux-Versionen, indem Sie den SoftwaresammlungenKanal.
Node.js ist Teil des SC-Kanals, der aktuell als Version 0.10 unterstützt wird, das scheint also ungefähr richtig zu sein.
Antwort2
Warum EPEL nicht die neuesten Versionen enthält, entnommen aus demEPEL-Leitlinien und -Richtlinien:
Warum kein Rolling Release mit den neuesten Paketen, wie sie in Fedora Extras enthalten waren?
Warum sollten wir das tun? Das ist genau das, was Fedora Extras getan hat und was auch funktioniert und gut funktioniert – aber das liegt hauptsächlich daran, dass Fedora (Core) viele Updates und ein nahezu rollierendes Release-Schema/schnellen Release-Zyklus hat. Aber das Enterprise Linux, auf dem wir aufbauen, ist viel vorsichtiger mit Updates und hat einen längeren Lebenszyklus; daher sollten wir das Gleiche für EPEL tun, da die meisten Benutzer es zu Recht so bevorzugen, da sie aus bestimmten Gründen eine stabile Distribution gewählt haben – wenn sie die neuesten Pakete wollen, hätten sie sich vielleicht für Fedora entschieden.
Sicher, es gibt viele Bereiche, in denen eine Mischung aus einer stabilen Basis und einer Reihe ganz neuer Pakete darauf erwünscht ist.VielleichtDas EPEL-Projekt wird für diese Fälle langfristig eine Lösung bieten (parallel zum sorgfältig aktualisierten Repository!), aber nicht für den Anfang. Es gibt bereits Repositorien von Drittanbietern, die etwas in dieser Richtung bieten, sodass Benutzer möglicherweise bereits von ihnen profitieren.
Außerdem: Ein Rolling-Release-Schema wie bei Fedora Extras ist für viele EPEL-Pakete aus einem anderen Grund nicht möglich: Neue Pakete erfordern oft neue Versionen bestimmter Kernbibliotheken. Dies wird bei EPEL zu Problemen führen, da wir keine aktualisierten Bibliotheken bereitstellen können, da dies Bibliotheken im Kernbetriebssystem ersetzen würde.
Beispiel: Dieses Dokument wurde ungefähr zu der Zeit geschrieben, als RHEL5 veröffentlicht wurde. Viele Pakete, die für RHEL5 erstellt werden, können zu diesem Zeitpunkt bereits nicht für RHEL4 erstellt werden, da das RHEL4-gtk2-Paket zwei Jahre alt ist und für viele aktuelle Anwendungen zu alt ist, da sie von einem neueren gtk2 abhängen. Selbst wenn wir also versuchen würden, ein rollierendes Schema mit ganz neuen Paketen zu haben, würden wir scheitern, da wir aufgrund dieser Abhängigkeiten von Bibliotheken nicht viele Pakete erstellen können. Am Ende hätten wir ein Repo mit einigen ganz neuen Paketen, während andere noch recht alt sind. Diese Mischung würde weder die Seite mit den „neuesten Versionen“ noch die Seite mit den „nur vorsichtigen Updates“ glücklich machen. Daher versuchen wir, die Seite mit den „nur vorsichtigen Updates“ anzusprechen. Denken Sie daran, dass der Support- und Updatezyklus von EPEL viel länger ist als der von Fedora.