Comment installer 2 versions différentes de java sur la même machine depuis EPEL
Le titre dit tout. Je veux avoir 2 versions de java sur la même machine. Par exemple 14.0.1.7et 14.0.2.12(qui sont tous deux dans le repo EPEL7).
Si je les installe un par un via yum, yum supprimera la première version et ne conservera que la dernière. Si je les installe via les rpmdépendances sont résolues mais pas installées automatiquement. Si j'installe d'abord avec yumet rpmensuite avec, cela fonctionne et il conserve les deux versions mais rpmn'installe aucune dépendance supplémentaire si le pop-out à un moment donné et ce serait cool de pouvoir le faire via un seul outil.
Tous les java mentionnés sont OpenJDK; EPEL7 a ces paquets de roulement (par exemple: java-14-openjdk-14.0.1.7-2.rolling.el7.x86_64, java-14-openjdk-14.0.2.12-1.rolling.el7.x86_64).
Des idées?
Réponses
Vous ne le faites pas. Mettez à niveau vers le dernier package, qui contient des correctifs
java-latest-openjdk 14.0.2.12-1remplace 14.0.1.7-2. Les miroirs EPEL ne porteront pas l'ancienne version, comme c'est leur politique habituelle.
Les notes de publication en amont indiquent que la version de sécurité 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: obtenir 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.
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 essaient de vous aider à vous tenir au courant de la dernière version des packages de votre système. C'est pourquoi il est courant de trouver des gestionnaires de paquets alternatifs comme 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 peut signifier que vous êtes limité sur l'accès Internet. Cela pourrait être un problème. En général, ces gestionnaires de packages alt 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'infos si besoin et bonne chance!
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, une fois pourrait se procurer une image de base CentOS ou RHEL, ajouter des référentiels et installer les packages de votre choix.
Il importe quel est le cas d'utilisation ici, et si l'objectif peut être exprimé via des conteneurs. Dans la plupart des cas, cela peut être le cas. Voici un exemple de fichier docker:
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 constitué, mais il 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 du fait que vous pouvez exposer une adresse IP entière (un peu comme une machine virtuelle). Vous pouvez également utiliser une VM. Les deux sont plus complexes qu'une solution basée sur un docker qui expose une seule combinaison IP / port par application.