Solution 1 :
Vous ne le faites pas. Mettez à niveau vers le package le plus récent, qui contient des correctifs.
java-latest-openjdk 14.0.2.12-1 remplace 14.0.1.7-2 . Les miroirs EPEL ne porteront pas l'ancienne version, comme c'est leur politique habituelle.
Les notes de version en amont indiquent que la version corrigée de sécurité de 14 est 14.0.2+12 . Notez les données de fuseau horaire habituelles et les changements de certificat x509, ainsi que les corrections de bogues. Demandez-vous si vous avez vraiment besoin d'épingler cette version. La documentation indique qu'il s'agit d'une version de maintenance mineure que vous êtes censé prendre.
Si vous identifiez un besoin de conserver la version précédente, deux problèmes à résoudre :récupérer le package et l'installer. L'ancienne version n'est plus sur les miroirs, pensez à configurer votre propre miroir privé ou proxy de mise en cache pour archiver les anciennes versions. Et, ces deux versions ne peuvent pas être installées en parallèle. Recherchez un moyen d'avoir deux environnements parallèles, qu'il s'agisse de conteneurs, de machines virtuelles ou d'utilitaires de gestion d'exécution qui vous permettent spécifiquement de sélectionner un environnement d'exécution Java.
Solution 2 :
Réponse courte :utilisez un gestionnaire d'exécution Java tel que SDKMAN ! ou jEnv
Réponse longue :par défaut, les gestionnaires de packages tentent de vous aider à rester à jour avec la dernière version des packages de votre système. C'est pourquoi il est courant de trouver des gestionnaires de packages alternatifs comme ceux ci-dessus pour différents langages (pyenv ou conda pour python, nvm pour node/js, etc.).
Vous mentionnez que c'est pour EPEL, ce qui pourrait signifier que vous êtes limité sur l'accès à Internet. Cela pourrait être un problème. En général, ces gestionnaires de packages alternatifs sont installés dans la session utilisateur et les variables d'environnement contrôlées n'affectent que l'utilisateur actuel. Cela peut être un avantage ou un inconvénient en fonction de ce sur quoi vous travaillez exactement.
Sans plus d'informations, je pense que l'utilisation des outils existants mentionnés ci-dessus (il pourrait y en avoir de plus récents) pourrait être un bon point de départ. N'hésitez pas à ajouter plus d'informations si nécessaire et bonne chance !
Solution 3 :
Il s'agit de l'un des principaux cas d'utilisation de Docker, dans lequel un conteneur peut contenir différentes bibliothèques de prise en charge et/ou différentes versions d'application dans leurs propres environnements isolés sans la surcharge et la complexité de la virtualisation.
Dans le Dockerfile le plus simple, on peut sourcer une image de base CentOS ou RHEL, ajouter des référentiels et installer les packages souhaités.
Peu importe le cas d'utilisation ici et si l'objectif peut être exprimé via des conteneurs. Dans la plupart des cas, cela peut l'être. Voici un exemple de 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]
Ce dernier bloc est presque entièrement composé, mais est valide. Si vous pouvez exprimer votre application en tant que microservice, cette solution basée sur Docker peut avoir beaucoup de sens.
Sinon, vous pouvez obtenir des résultats similaires avec un conteneur LXD, à l'exception que vous pouvez exposer une adresse IP entière (un peu comme une machine virtuelle). Vous pouvez également utiliser une machine virtuelle. Les deux sont plus complexes qu'une solution basée sur Docker qui expose une seule combinaison IP/port par application.