Bug 1467960 - Bug 1413543 results in unexpected results during routine updates
Bug 1413543 results in unexpected results during routine updates
Status: NEW
Product: Red Hat Software Collections
Classification: Red Hat
Component: javapackages-tools (Show other bugs)
rh-java-common
Unspecified Unspecified
unspecified Severity high
: ---
: 3.1
Assigned To: Mikolaj Izdebski
BaseOS QE - Apps
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-05 11:59 EDT by Kyle Walker
Modified: 2017-10-04 11:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kyle Walker 2017-07-05 11:59:21 EDT
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.
Comment 5 Kyle Walker 2017-07-06 08:48:41 EDT
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
Comment 6 Mikolaj Izdebski 2017-07-06 09:26:39 EDT
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.
Comment 7 Kyle Walker 2017-07-06 10:10:02 EDT
(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

Note You need to log in before you can comment on or make changes to this bug.