Solusi 1:
Anda tidak. Tingkatkan ke paket selanjutnya, yang memiliki perbaikan.
java-latest-openjdk 14.0.2.12-1 menggantikan 14.0.1.7-2 . Mirror EPEL tidak akan membawa versi lama, seperti kebijakan biasanya.
Catatan rilis upstream mengatakan versi patch keamanan 14 adalah 14.0.2+12 . Perhatikan data zona waktu yang biasa dan perubahan sertifikat x509, plus perbaikan bug. Pikirkan apakah Anda benar-benar perlu menyematkan versi ini. Dokumentasi menunjukkan bahwa ini adalah rilis pemeliharaan kecil yang ingin Anda ambil.
Jika Anda mengidentifikasi kebutuhan untuk mempertahankan versi sebelumnya, ada dua masalah yang harus diselesaikan:mendapatkan paket dan menginstalnya. Versi lama tidak lagi ada di mirror, pertimbangkan untuk menyiapkan mirror pribadi Anda sendiri atau proxy caching untuk mengarsipkan versi lama. Dan, kedua versi ini tidak bisa dipasang secara paralel. Selidiki cara untuk memiliki dua lingkungan paralel, baik kontainer, mesin virtual, atau utilitas pengelola waktu proses yang secara khusus memungkinkan Anda memilih waktu proses Java.
Solusi 2:
Jawaban singkat:Gunakan manajer runtime java seperti SDKMAN! atau jEnv
Jawaban panjang:Secara default, manajer paket mencoba untuk membantu tetap mendapatkan versi terbaru dari paket di sistem Anda. Inilah sebabnya mengapa sangat umum untuk menemukan manajer paket alternatif seperti di atas untuk bahasa yang berbeda (pyenv atau conda untuk python, nvm untuk node/js, dll).
Anda menyebutkan ini untuk EPEL yang mungkin berarti Anda dibatasi pada akses internet. Ini mungkin menjadi masalah. Secara umum meskipun pengelola paket alt ini dipasang di sesi pengguna dan variabel lingkungan yang dikontrol hanya memengaruhi pengguna saat ini. Ini mungkin keuntungan atau kerugian tergantung pada apa yang sebenarnya sedang Anda kerjakan.
Tanpa informasi lebih lanjut saya pikir menggunakan alat yang ada yang disebutkan di atas (btw mungkin ada yang lebih baru) mungkin merupakan tempat yang baik untuk memulai. Jangan ragu untuk menambahkan lebih banyak info jika diperlukan dan semoga berhasil!
Solusi 3:
Ini adalah salah satu kasus penggunaan utama untuk Docker, di mana kontainer dapat berisi pustaka pendukung yang berbeda dan/atau versi aplikasi yang berbeda di lingkungan terisolasi mereka sendiri tanpa overhead dan kompleksitas virtualisasi.
Di Dockerfile yang paling sederhana, sekali dapat mengambil image dasar CentOS atau RHEL, menambahkan repositori, dan menginstal paket yang Anda inginkan.
Penting apa kasus penggunaan di sini, dan jika tujuannya dapat diungkapkan melalui wadah. Dalam kebanyakan kasus, itu bisa terjadi. Berikut adalah contoh 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]
Blok terakhir itu hampir seluruhnya dibuat-buat, tetapi valid. Jika Anda dapat mengekspresikan aplikasi Anda sebagai layanan mikro, solusi berbasis buruh pelabuhan ini bisa sangat masuk akal.
Jika tidak, Anda dapat memperoleh hasil yang serupa dengan wadah LXD, dengan pengecualian bahwa Anda dapat mengekspos seluruh IP (seperti VM). Anda juga bisa menggunakan VM. Keduanya lebih kompleks daripada solusi berbasis buruh pelabuhan yang memaparkan satu kombinasi IP/port per aplikasi.