Lösung 1:
Du nicht. Führen Sie ein Upgrade auf das neuere Paket durch, das Korrekturen enthält.
java-latest-openjdk 14.0.2.12-1 ersetzt 14.0.1.7-2 . EPEL-Mirrors tragen nicht die alte Version, wie es ihre übliche Richtlinie ist.
Die Versionshinweise der Originalautoren besagen, dass die Sicherheitspatch-Version von 14 14.0.2+12 ist . Beachten Sie die üblichen Zeitzonendaten und x509-Zertifikatsänderungen sowie Fehlerbehebungen. Überlegen Sie, ob Sie diese Version wirklich pinnen müssen. Die Dokumentation weist darauf hin, dass dies eine kleinere Wartungsversion ist, die Sie nehmen möchten.
Wenn Sie feststellen, dass Sie die vorherige Version behalten müssen, müssen Sie zwei Probleme lösen:das Paket erhalten und es installieren. Die alte Version befindet sich nicht mehr auf den Mirrors, erwägen Sie, Ihren eigenen privaten Mirror oder Caching-Proxy einzurichten, um alte Versionen zu archivieren. Und diese beiden Versionen können nicht parallel installiert werden. Untersuchen Sie eine Möglichkeit, zwei parallele Umgebungen zu haben, seien es Container, virtuelle Maschinen oder Runtime-Manager-Dienstprogramme, die es Ihnen ausdrücklich ermöglichen, eine Java-Laufzeitumgebung auszuwählen.
Lösung 2:
Kurze Antwort:Verwenden Sie einen Java-Laufzeitmanager wie SDKMAN! oder jEnv
Lange Antwort:Standardmäßig versuchen Paketmanager, mit der neuesten Version der Pakete in Ihrem System auf dem Laufenden zu bleiben. Aus diesem Grund ist es üblich, alternative Paketmanager wie den obigen für verschiedene Sprachen zu finden (pyenv oder conda für Python, nvm für node/js usw.).
Sie erwähnen, dass dies für EPEL gilt, was bedeuten könnte, dass Ihr Internetzugang eingeschränkt ist. Dies könnte ein Problem sein. Im Allgemeinen werden diese alternativen Paketmanager jedoch in der Benutzersitzung installiert und die gesteuerten Umgebungsvariablen wirken sich nur auf den aktuellen Benutzer aus. Dies kann ein Vor- oder Nachteil sein, je nachdem, woran Sie genau arbeiten.
Ohne weitere Informationen denke ich, dass die Verwendung der oben genannten vorhandenen Tools (übrigens könnte es neuere geben) ein guter Anfang sein könnte. Fühlen Sie sich frei, bei Bedarf weitere Informationen hinzuzufügen und viel Glück!
Lösung 3:
Dies ist einer der Hauptanwendungsfälle für Docker, bei dem ein Container unterschiedliche unterstützende Bibliotheken und/oder unterschiedliche Anwendungsversionen in ihren eigenen isolierten Umgebungen enthalten kann, ohne den Overhead und die Komplexität der Virtualisierung.
In der einfachsten Docker-Datei könnte man ein CentOS- oder RHEL-Basis-Image beziehen, Repositories hinzufügen und die gewünschten Pakete installieren.
Es ist wichtig, was hier der Anwendungsfall ist und ob das Ziel über Container ausgedrückt werden kann. In den meisten Fällen kann es sein. Hier ist ein Beispiel für eine Docker-Datei:
FROM centos
RUN yum update -y
RUN yum install -y epel-release
RUN yum install -y java-14-openjdk-14.0.1.7-2.rolling.el7.x86_64
ENV JAVA_HOME /etc/alternatives/jre
WORKDIR /app
EXPOSE 8080
CMD [run.sh]
Dieser letzte Block ist fast vollständig erfunden, aber gültig. Wenn Sie Ihre Anwendung als Microservice ausdrücken können, kann diese Docker-basierte Lösung sehr sinnvoll sein.
Ansonsten können Sie mit einem LXD-Container ähnliche Ergebnisse erzielen, mit der Ausnahme, dass Sie eine vollständige IP-Adresse (ähnlich wie bei einer VM) verfügbar machen können. Sie können auch eine VM verwenden. Beide sind komplexer als eine Docker-basierte Lösung, die eine einzelne IP/Port-Kombination pro Anwendung verfügbar macht.