Title says it all. I want to have 2 versions of java on the same machine. For example 14.0.1.7
and 14.0.2.12
(which are both in EPEL7 repo).
If i install them one by one via yum
, yum will remove first version and keep just the last. If I install them via rpm
dependencies are resolved but not installed automatically. If i install first with yum
and second with rpm
then it works and it keeps both versions but rpm
won't install any additional dependencies if the pop out at some point and it would be cool to be able to do it via only one tool.
All mentioned java are OpenJDK; EPEL7 has these rolling packages (for example: java-14-openjdk-14.0.1.7-2.rolling.el7.x86_64
, java-14-openjdk-14.0.2.12-1.rolling.el7.x86_64
).
Any ideas?
You don't. Upgrade to the later package, which has fixes.
java-latest-openjdk
14.0.2.12-1
replaces14.0.1.7-2
. EPEL mirrors won't carry the old version, as is their usual policy.The upstream release notes say the security patched version of 14 is
14.0.2+12
. Note the usual time zone data and x509 cert changes, plus bug fixes. Think about whether you really need to pin this version. The documentation indicates this to be a minor maintenance release you are intended to take.If you identify a need to keep the previous version, two problems to resolve: getting the package and installing it. The old version is no longer on the mirrors, consider setting up your own private mirror or caching proxy to archive old versions. And, these two versions cannot be installed in parallel. Investigate a way to have two parallel environments, whether containers, virtual machines, or runtime manager utilities which specifically allow you to select a Java runtime.
Short answer: Use a java runtime manager such as SDKMAN! or jEnv
Long answer: By default, package managers are trying to help keep up to date with the latest version of the packages in your system. This is why it is common to find alternative package managers like the above for different languages (pyenv or conda for python, nvm for node/js, etc).
You mention this is for EPEL which might mean you are restricted on the internet access. This might be an issue. In general though these alt package managers are installed in the user session and the environment variables controlled affect only the current user. This might be an advantage or disadvantage depending on what exactly you are working on.
Without more information I think using the existing tools mentioned above (btw there might be newer ones) might be a good place to start. Feel free to add more info if needed and good luck!
This is one of the primary use-cases for Docker, in which a container can contain differing supporting libraries and/or differing application versions in their own isolated environments without the overhead and complexity of virtualization.
In the simplest Dockerfile, once could source a CentOS or RHEL base image, add repositories, and install the packages you want.
It matters what the use-case is here, and if the goal can be expressed via containers. In most cases, it can be. Here's an example dockerfile:
That last block is almost entirely made up, but is valid. If you can express your application as a microservice, this docker-based solution can make a lot of sense.
Otherwise, you can accomplish similar results with an LXD container, with the exception that you can expose an entire IP (much like a VM). You could also use a VM. Both are more complex than a docker based solution that exposes a single IP/port combination per application.
Check This post, Redhat web
https://access.redhat.com/node/3040171
Regards.