Řešení 1:
Ty ne. Upgradujte na novější balíček, který obsahuje opravy.
java-latest-openjdk 14.0.2.12-1 nahrazuje 14.0.1.7-2 . Zrcadla EPEL nenesou starou verzi, jak je jejich obvyklou zásadou.
Upstream poznámky k vydání říkají, že bezpečnostní opravená verze 14 je 14.0.2+12 . Všimněte si obvyklých údajů o časovém pásmu a změn certifikátů x509 plus opravy chyb. Přemýšlejte o tom, zda tuto verzi opravdu potřebujete připnout. Dokumentace uvádí, že se jedná o vydání menší údržby, které máte v úmyslu provést.
Pokud zjistíte, že je třeba zachovat předchozí verzi, je třeba vyřešit dva problémy:získání balíčku a jeho instalace. Stará verze již není na zrcadlech, zvažte nastavení vlastního soukromého zrcadla nebo caching proxy pro archivaci starých verzí. A tyto dvě verze nelze nainstalovat paralelně. Prozkoumejte způsob, jak mít dvě paralelní prostředí, ať už kontejnery, virtuální stroje nebo obslužné programy správce runtime, které vám konkrétně umožňují vybrat běhové prostředí Java.
Řešení 2:
Krátká odpověď:Použijte správce Java runtime, jako je SDKMAN! nebo jEnv
Dlouhá odpověď:Ve výchozím nastavení se správci balíčků snaží pomáhat udržovat aktuální verzi balíčků ve vašem systému. To je důvod, proč je běžné najít alternativní správce balíčků, jako je výše uvedený, pro různé jazyky (pyenv nebo conda pro python, nvm pro node/js atd.).
Uvádíte, že je to pro EPEL, což může znamenat, že máte omezený přístup k internetu. To může být problém. Obecně platí, že tyto alt správci balíčků jsou nainstalovány v uživatelské relaci a řízené proměnné prostředí ovlivňují pouze aktuálního uživatele. To může být výhoda nebo nevýhoda v závislosti na tom, na čem přesně pracujete.
Bez dalších informací si myslím, že použití stávajících nástrojů uvedených výše (mimo jiné mohou být i novější) by mohlo být dobrým místem, kde začít. V případě potřeby můžete přidat další informace a hodně štěstí!
Řešení 3:
Toto je jeden z primárních případů použití pro Docker, ve kterém může kontejner obsahovat různé podpůrné knihovny a/nebo různé verze aplikací v jejich vlastních izolovaných prostředích bez režie a složitosti virtualizace.
V nejjednodušším Dockerfile by bylo možné vytvořit zdroj základního obrazu CentOS nebo RHEL, přidat úložiště a nainstalovat balíčky, které chcete.
Záleží na tom, jaký je zde případ použití a zda lze cíl vyjádřit pomocí kontejnerů. Ve většině případů může být. Zde je příklad dockerfile:
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]
Tento poslední blok je téměř celý vymyšlený, ale je platný. Pokud můžete svou aplikaci vyjádřit jako mikroslužbu, toto řešení založené na dockeru může mít velký smysl.
Jinak můžete dosáhnout podobných výsledků s kontejnerem LXD s tou výjimkou, že můžete vystavit celou IP (podobně jako virtuální počítač). Můžete také použít VM. Oba jsou složitější než řešení založené na dockeru, které odhaluje jedinou kombinaci IP/port na aplikaci.