Soluzione 1:
Tu no. Aggiorna al pacchetto successivo, che contiene correzioni.
java-latest-openjdk 14.0.2.12-1 sostituisce 14.0.1.7-2 . I mirror EPEL non manterranno la vecchia versione, come è la loro solita politica.
Le note di rilascio upstream dicono che la versione con patch di sicurezza di 14 è 14.0.2+12 . Nota i soliti dati sul fuso orario e le modifiche al certificato x509, oltre alle correzioni di bug. Pensa se hai davvero bisogno di appuntare questa versione. La documentazione indica che si tratta di una versione di manutenzione minore che intendi utilizzare.
Se identifichi la necessità di mantenere la versione precedente, due problemi da risolvere:ottenere il pacchetto e installarlo. La vecchia versione non è più sui mirror, considera di configurare il tuo mirror privato o il proxy di memorizzazione nella cache per archiviare le vecchie versioni. Inoltre, queste due versioni non possono essere installate in parallelo. Studia un modo per avere due ambienti paralleli, siano essi contenitori, macchine virtuali o utilità di gestione del runtime che ti consentano specificamente di selezionare un runtime Java.
Soluzione 2:
Risposta breve:usa un gestore di runtime Java come SDKMAN! o jEnv
Risposta lunga:per impostazione predefinita, i gestori di pacchetti cercano di mantenersi aggiornati con l'ultima versione dei pacchetti nel sistema. Questo è il motivo per cui è comune trovare gestori di pacchetti alternativi come il precedente per lingue diverse (pyenv o conda per python, nvm per node/js, ecc.).
Dici che questo è per EPEL, il che potrebbe significare che sei limitato nell'accesso a Internet. Questo potrebbe essere un problema. In generale, tuttavia, questi gestori di pacchetti alt sono installati nella sessione utente e le variabili di ambiente controllate influenzano solo l'utente corrente. Questo potrebbe essere un vantaggio o uno svantaggio a seconda di cosa esattamente stai lavorando.
Senza ulteriori informazioni, penso che utilizzare gli strumenti esistenti sopra menzionati (tra l'altro potrebbero essercene di nuovi) potrebbe essere un buon punto di partenza. Sentiti libero di aggiungere altre informazioni se necessario e buona fortuna!
Soluzione 3:
Questo è uno dei casi d'uso principali per Docker, in cui un contenitore può contenere diverse librerie di supporto e/o diverse versioni dell'applicazione nei propri ambienti isolati senza il sovraccarico e la complessità della virtualizzazione.
Nel Dockerfile più semplice, once potrebbe procurarsi un'immagine di base CentOS o RHEL, aggiungere repository e installare i pacchetti desiderati.
Importa qual è il caso d'uso qui e se l'obiettivo può essere espresso tramite contenitori. Nella maggior parte dei casi, può esserlo. Ecco un dockerfile di esempio:
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]
Quest'ultimo blocco è quasi interamente composto, ma è valido. Se puoi esprimere la tua applicazione come un microservizio, questa soluzione basata su docker può avere molto senso.
Altrimenti, puoi ottenere risultati simili con un contenitore LXD, con l'eccezione che puoi esporre un intero IP (molto simile a una VM). Potresti anche usare una VM. Entrambi sono più complessi di una soluzione basata su docker che espone una singola combinazione IP/porta per applicazione.