Description of problem: Bug 1413543 altered the "Requires:" directives for the package from the previous full "java" entry to a "java-headless" option. For existing installations that already have the full JRE installed, this will result in an additional java-headless package being installed and overriding previous configurations. Version-Release number of selected component (if applicable): rh-java-common-javapackages-tools-4.3.2-1.14.el6.noarch How reproducible: Easily Steps to Reproduce: 1. Install as well as a base java runtime 2. Issue a yum update 3. Actual results: rh-java-common-javapackages-tools-4.3.2-1.14.el6.noarch pulls in a java-headless package Expected results: The existing java package satisfy the requirement Additional info: This pulling in of an unexpected java-headless package can cause issues for installations that have a base JRE for Java 1.7 installations.
More detailed reproducer steps: 1 - Starting from a clean state. ~~~~ # rpm -qa | grep ^java ~~~~ 2 - Installing the base java-*-ibm revision and verifying where the alternatives side is pointing. ~~~~ # yum install java-1.7.1-ibm -y <snip> # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 42 Jul 6 08:26 /etc/alternatives/java -> /usr/lib/jvm/jre-1.7.1-ibm.x86_64/bin/java ~~~~ 3 - Installing the rh-java-common-javapackages-tools package, which succeeds as the java-*-ibm package satisfies the requirements for the package. ~~~~ # yum install rh-java-common-javapackages-tools-4.3.2-1.11.el6 -y <snip> # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 42 Jul 6 08:26 /etc/alternatives/java -> /usr/lib/jvm/jre-1.7.1-ibm.x86_64/bin/java ~~~~ 4 - You can install java-1.8.0-openjdk-headless and reproduce the same behaviour. As determined by the alternatives priority being higher. This would be an expected state where a manual "alternatives" override would be necessary. ~~~~ # yum install java-1.8.0-openjdk -y <snip> # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 46 Jul 6 08:29 /etc/alternatives/java -> /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java ~~~~ 5 - Undoing the previous operation and making sure that we revert to the previous java-*-ibm revision. ~~~~ # yum history undo last -y <snip> # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 42 Jul 6 08:30 /etc/alternatives/java -> /usr/lib/jvm/jre-1.7.1-ibm.x86_64/bin/java ~~~~ 6 - Reproducing the exact issue here. ~~~~ # yum update rh-java-common-javapackages-tools -y <snip> # ls -l /etc/alternatives/java lrwxrwxrwx. 1 root root 46 Jul 6 08:30 /etc/alternatives/java -> /usr/lib/jvm/jre-1.8.0-openjdk.x86_64/bin/java ~~~~ The final update step pulls in the java-1.8.0-openjdk-headless RPM and overrides the already installed java-1.7.1-ibm version. The dependency is not actually valid as the java-1.7.1-ibm package includes the necessary java functionality. If it were possible, though I don't believe it is within the RPM packaging spec, it would be better to have a conditional dependency of java OR java-headless. Though, I do not believe that is possible at the moment. Kyle Walker Senior Software Maintenance Engineer - SEG North America
I can agree that dependency on "java-headless" is slightly too strict as "java-headless OR java" would work too. But as you said, boolean dependencies are not implemented in RHEL yet, so this can't be fixed without reverting bug#1413543. This is a minor IMO, as in *some* cases it may lead to installing unnecessary package. A different issue is that the user needs specific Java version, but they haven't configured alternatives for that. In this case they can't expect default setting not to change over time. Even if rh-java-common is "fixed" not to bring in java-1.8.0-openjdk-headless, that package may be installed as dependency of any other package in future.
(In reply to Mikolaj Izdebski from comment #6) > I can agree that dependency on "java-headless" is slightly too strict as > "java-headless OR java" would work too. But as you said, boolean > dependencies are not implemented in RHEL yet, so this can't be fixed without > reverting bug#1413543. This is a minor IMO, as in *some* cases it may lead > to installing unnecessary package. It could, though I would say that in the event that this possibility is something that we really don't want to pursue, the current behaviour would require us to update all of the supplementary java packages so that the superset (Provides: java) also indicates that it supplies the subset functionality (Provides: java java-headless). I doubt that would be without issues as well. > A different issue is that the user needs specific Java version, but they > haven't configured alternatives for that. In this case they can't expect > default setting not to change over time. Even if rh-java-common is "fixed" > not to bring in java-1.8.0-openjdk-headless, that package may be installed > as dependency of any other package in future. I do agree that there are ways around this type of thing, but this type of "defaults suddenly don't work during routine patching though they always have" is sure to cause issues in customers environments. Kyle Walker Senior Software Maintenance Engineer - SEG North America
In accordance with the Red Hat Software Collections Product Life Cycle, the support period for this collection has ended. New bug fix, enhancement, and security errata updates, as well as technical support services will no longer be made available for this collection. Customers are encouraged to upgrade to a later release. Please contact Red Hat Support if you have further questions, or refer to the support lifecycle page for more information. https://access.redhat.com/support/policy/updates/rhscl/