Solución 1:
tu no Actualice al paquete posterior, que tiene correcciones.
java-latest-openjdk 14.0.2.12-1 reemplaza 14.0.1.7-2 . Los espejos EPEL no llevarán la versión anterior, como es su política habitual.
Las notas de la versión anterior dicen que la versión con parches de seguridad de 14 es 14.0.2+12 . Tenga en cuenta los datos habituales de la zona horaria y los cambios en el certificado x509, además de las correcciones de errores. Piensa si realmente necesitas anclar esta versión. La documentación indica que se trata de una versión de mantenimiento menor que debe realizar.
Si identifica la necesidad de mantener la versión anterior, dos problemas para resolver:obtener el paquete e instalarlo. La versión anterior ya no está en los espejos, considere configurar su propio espejo privado o un proxy de almacenamiento en caché para archivar versiones antiguas. Y estas dos versiones no se pueden instalar en paralelo. Investigue una forma de tener dos entornos paralelos, ya sean contenedores, máquinas virtuales o utilidades del administrador de tiempo de ejecución que le permitan seleccionar específicamente un tiempo de ejecución de Java.
Solución 2:
Respuesta corta:¡Use un administrador de tiempo de ejecución de Java como SDKMAN! o jEnv
Respuesta larga:De manera predeterminada, los administradores de paquetes intentan ayudarlo a mantenerse actualizado con la última versión de los paquetes en su sistema. Es por esto que es común encontrar administradores de paquetes alternativos como el anterior para diferentes lenguajes (pyenv o conda para python, nvm para node/js, etc).
Usted menciona que esto es para EPEL, lo que podría significar que está restringido en el acceso a Internet. Esto podría ser un problema. En general, aunque estos administradores de paquetes alternativos se instalan en la sesión del usuario y las variables de entorno controladas afectan solo al usuario actual. Esto puede ser una ventaja o una desventaja dependiendo de en qué estés trabajando exactamente.
Sin más información, creo que usar las herramientas existentes mencionadas anteriormente (por cierto, puede haber otras más nuevas) podría ser un buen lugar para comenzar. Siéntase libre de agregar más información si es necesario y ¡buena suerte!
Solución 3:
Este es uno de los principales casos de uso de Docker, en el que un contenedor puede contener diferentes bibliotecas de soporte y/o diferentes versiones de aplicaciones en sus propios entornos aislados sin la sobrecarga y la complejidad de la virtualización.
En el Dockerfile más simple, una vez podría obtener una imagen base de CentOS o RHEL, agregar repositorios e instalar los paquetes que desee.
Importa cuál es el caso de uso aquí y si el objetivo se puede expresar a través de contenedores. En la mayoría de los casos, puede serlo. Aquí hay un archivo docker de ejemplo:
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]
Ese último bloque está compuesto casi en su totalidad, pero es válido. Si puede expresar su aplicación como un microservicio, esta solución basada en Docker puede tener mucho sentido.
De lo contrario, puede lograr resultados similares con un contenedor LXD, con la excepción de que puede exponer una IP completa (como una VM). También podría usar una máquina virtual. Ambos son más complejos que una solución basada en docker que expone una única combinación de puerto/IP por aplicación.