Bug 1175457
| Summary: | modern Java RPMs not tagged to provide 'java-gcj-compat' feature | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | matthew patton <pattonme> |
| Component: | java-1.7.0-openjdk | Assignee: | jiri vanek <jvanek> |
| Status: | CLOSED CANTFIX | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 6.5 | CC: | dbhole, edewata, eliasen, jvanek, mkosek, mpoole, nkinder, nsoman, omajid, sbaiduzh, vonsch |
| Target Milestone: | rc | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-08-27 08:04:11 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1172231, 1211995 | ||
Just a few of the packages that depend on java-gcj-compat that keep triggering the inclusion of the significantly out of date JRE. rpm -q --whatrequires java-gcj-compat java_cup-0.10k-5.el6.x86_64 sinjdoc-0.5-9.1.el6.x86_64 jakarta-commons-pool-1.3-12.7.el6.x86_64 classpathx-jaf-1.0-15.4.el6.x86_64 xml-commons-apis-1.3.04-3.6.el6.x86_64 log4j-1.2.14-6.4.el6.x86_64 xml-commons-resolver-1.1-4.18.el6.x86_64 regexp-1.5-4.4.el6.x86_64 bcel-5.2-7.2.el6.x86_64 jakarta-commons-daemon-1.0.1-8.9.el6.x86_64 ecj-3.4.2-6.el6.x86_64 jakarta-commons-httpclient-3.1-0.9.el6_5.x86_64 also needs to provide 'jaxp_parser_impl' please do *NOT* (re-)introduce java-gcj-compat requiring 'sinjdoc'. That is clearly bogus. The requirement goes the other direction. I question mx4j requiring 'bcel'. Hi, Tomcat is available on all architectures on el6. OpenJDK is only available for x86 and x86_64 -- making OpenJDK provide gcj-compat will satisfy the requirement on only certain architectures, leading to inconsistency in build JDKs across architectures. The same holds for the other packages you listed, I believe. I am going to close this as WONTFIX as the behavior is correct from JDK perspective. If wrong JDK being pulled in is an issue, please bring this up with the respective component owners. You COMPLETELY missed the point!! It doesn't matter if OpenJDK is only available in x86/64bit. The current setup means I can *NEVER* remove the blasted java-1.5.0-gcj by virtue of the dependency chain. Any and *ALL* JDK packages need to be tagged with having features java-gcj-compat and jaxp_parser_impl. If on sparc, mips, or some other obscure and dying architectures still need java-1.5.0-gcj because it's the only option, don't have a OpenJDK implementation, or the only option for a modern JRE is 3rd party tarball from Oracle, that's perfectly fine. This matter is akin to cronie-anacron and cronie-noanacron. RHEL defaults to installing the anacron version but we are able to rip it out and substitute -noanacron because it provides the same RPM feature tags. I'm NOT asking that the default package be changed away from java-1.5.0-gcj, but rather I should be allowed to install OpenJDK-1.7 after the fact and then remove java-1.5.0-gcj and for it do it cleanly without triggering a mass-uninstall because OpenJDK hasn't been tagged properly. OpenJDK-* and java-1.5.0-gcj are identical in role and capabilities, the RPM's feature attributes simply need to be updated to reflect that fact. I understand what you are asking and I am telling you that that will cause inconsistencies in the build root. Take for example log4j that you mentioned. Currently it requires java-1.5.0-gcj. If OpenJDK RPM was to provide this requirement, it may be pulled in (yum does not guarantee which package is pulled in if multiple packages provide a requirement). If OpenJDK is pulled in, it will supersede java-1.5.0-gcj and become the default build JDK for that buildroot, thus causing tomcat to be built with OpenJDK instead of with GCJ. The most obvious way to get around this is to blacklist OpenJDK from the buildroot, but that does not address any customers who rebuild packages on their end. What you are proposing is not impossible, but it is not under the sole purview of OpenJDK. It is of least concern to OpenJDK and most to the packages (requiring gcj-compat) themselves which is why I said you should talk to their maintainers first. Furthermore, this issue should be opened as an RFE against the RHEL distribution as this is not a bug in OpenJDK packaging. This issue has been addressed in RHEL-7 where GCJ is no longer present. I'll admit I look at the world thru Sysadmin glasses. I see what you're getting at but why should millions of users suffer and get dinged every time by security audits? It was Red Hat's choice to offer multiple alternative Java Runtimes. Every package that is not properly tagged is an incontrovertible bug - it's lying by omission. When I query RPM for features I have every right to expect I get the FULL and correct answer. You can't just pick and choose, "oh, i'll tag this package as a java interpreter but not these other 6 even though they are all equivalent because I can't be arsed to update our build config to blacklist everything that isn't the one we've chosen as the baseline." The whole point of the features described in RPM is so that the user can swap out equivalent packages. Sendmail vs Postfix is another example of equivalency and it works as it should. If I have both and then remove the other I don't get a massive RPM unwind. Now maybe 'java-gcj-compat' is a tag that just needs to go away in favor of plain old 'java'. I don't know the history behind it and 'jaxp_parser_impl'. If so, then there are a few dozen packages that need their dependencies updated to remove the aforementioned values. Or we could just fix OpenJDK (it's all of 1 line in a SPEC file! either as 'provides' or 'obsoletes') and the blacklist and the impact is minimal to the point nobody will even notice. That's how you do modular software. RHEL6 is supported for like 5 years right? I appreciate that RHEL7 has moved on from 1.5.0-gcj but even in RHEL7, it is an error for OpenJDK NOT to report all applicable features. I can't speak to RHEL7 because I don't run it. Jiri, can we do the above safely? I'm not sure if we can. I'm a bit afraid of it. IMHO the only correct solution is to get rid of all requires java-gcj-compat and start to require requires javaX Where X is correct name and version Most likely "java >= 1.5" for most of them and java = 1.5 for special cases. This is general answer. However - for rhe6 life-cycle, (that means rhel 6, no zstream) I think we may add java-gcj-compat to list of provides. With note that it is workaround, and will nor be supported in any future rhel. Of course if any level rhel6 testing will fail, this will really become closed as cantfix. Yeah, my worry with changing in the OpenJDK packages is as you stated, packages that specifically require 1.5 will fail and will not be noticed until they start failing. Can you generate a list of packages that need gcj compat? Perhaps we can mass mail the maintainers of those packages and ask them. repoquery --whatrequires java-gcj-compat adaptx-0:0.9.13-8.1.el6.x86_64 avalon-framework-0:4.1.4-7.el6.x86_64 bcel-0:5.2-7.2.el6.x86_64 bea-stax-0:1.2.0-0.5.rc1.2.el6.x86_64 bea-stax-api-0:1.2.0-0.5.rc1.2.el6.x86_64 castor-0:0.9.5-5.3.el6.x86_64 castor-demo-0:0.9.5-5.3.el6.x86_64 castor-test-0:0.9.5-5.3.el6.x86_64 castor-xml-0:0.9.5-5.3.el6.x86_64 classpathx-jaf-0:1.0-15.4.el6.x86_64 ecj-1:3.4.2-6.el6.x86_64 flute-0:1.3.0-3.OOo31.el6.x86_64 jakarta-commons-codec-0:1.3-11.7.el6.x86_64 jakarta-commons-daemon-1:1.0.1-8.9.el6.x86_64 jakarta-commons-daemon-jsvc-1:1.0.1-8.9.el6.x86_64 jakarta-commons-httpclient-1:3.1-0.9.el6_5.x86_64 jakarta-commons-pool-0:1.3-12.7.el6.x86_64 jakarta-oro-0:2.0.8-6.6.el6.x86_64 java_cup-1:0.10k-5.el6.x86_64 javacc-0:4.1-0.5.el6.x86_64 jcommon-serializer-0:0.3.0-3.1.el6.x86_64 jlex-0:1.2.6-9.5.el6.x86_64 junit-0:3.8.2-6.5.el6.x86_64 junit-demo-0:3.8.2-6.5.el6.x86_64 jython-0:2.2.1-4.8.el6.x86_64 jzlib-0:1.0.7-7.5.el6.x86_64 ldapjdk-0:4.18-6.el6.x86_64 libbase-0:1.0.0-3.OOo31.1.el6.x86_64 libfonts-0:1.0.0-3.OOo31.el6.x86_64 libformula-0:0.2.0-3.OOo31.1.el6.x86_64 liblayout-0:0.2.9-4.OOo31.el6.x86_64 libloader-0:1.0.0-2.OOo31.1.el6.x86_64 libreadline-java-0:0.8.0-24.3.el6.x86_64 librepository-0:1.0.0-2.OOo31.1.el6.x86_64 log4j-0:1.2.14-6.4.el6.x86_64 pentaho-libxml-0:1.0.0-2.OOo31.1.el6.x86_64 pentaho-reporting-flow-engine-1:0.9.2-5.OOo31.el6.x86_64 regexp-0:1.5-4.4.el6.x86_64 sac-0:1.3-5.1.el6.x86_64 sinjdoc-0:0.5-9.1.el6.x86_64 xml-commons-apis-0:1.3.04-3.6.el6.x86_64 xml-commons-resolver-0:1.1-4.18.el6.x86_64 From those flute-0:1.3.0-3.OOo31.el6.x86_64 javacc-0:4.1-0.5.el6.x86_64 libbase-0:1.0.0-3.OOo31.1.el6.x86_64 libfonts-0:1.0.0-3.OOo31.el6.x86_64 libformula-0:0.2.0-3.OOo31.1.el6.x86_64 liblayout-0:0.2.9-4.OOo31.el6.x86_64 libloader-0:1.0.0-2.OOo31.1.el6.x86_64 librepository-0:1.0.0-2.OOo31.1.el6.x86_64 pentaho-libxml-0:1.0.0-2.OOo31.1.el6.x86_64 pentaho-reporting-flow-engine-1:0.9.2-5.OOo31.el6.x86_64 regexp-0:1.5-4.4.el6.x86_64 sac-0:1.3-5.1.el6.x86_64 requires *also* java The list of owners is a bit suspicious: adaptx RHEL-6.0 akurtako avalon-framework RHEL-6.0 swagiaal bcel RHEL-6.0 jjohnstn bea-stax RHEL-6.0 patrickm castor RHEL-6.0 jjohnstn classpathx-jaf RHEL-6.0 jjohnstn ecj RHEL-6.0 dbhole flute RHEL-6.0 caolanm jakarta-commons-codec RHEL-6.0 swagiaal jakarta-commons-daemon RHEL-6.0 jjohnstn jakarta-commons-httpclient RHEL-6.0 jjohnstn jakarta-commons-pool RHEL-6.0 jjohnstn jakarta-oro RHEL-6.0 jjohnstn java_cup RHEL-6.0 patrickm javacc RHEL-6.0 jjohnstn jcommon-serializer RHEL-6.0 caolanm jlex RHEL-6.0 patrickm junit RHEL-6.0 swagiaal junit4 RHEL-6.0 akurtako jython RHEL-6.0 alee jzlib RHEL-6.0 jjohnstn ldapjdk RHEL-6.2 mharmsen libbase RHEL-6.0 caolanm libfonts RHEL-6.0 caolanm libformula RHEL-6.0 caolanm liblayout RHEL-6.0 caolanm libloader RHEL-6.0 caolanm libreadline-java RHEL-6.0 swagiaal librepository RHEL-6.0 caolanm log4j RHEL-6.0 jjohnstn pentaho-libxml RHEL-6.0 caolanm pentaho-reporting-flow-engine RHEL-6.0 caolanm regexp RHEL-6.0 swagiaal sac RHEL-6.0 caolanm sinjdoc RHEL-6.0 dbhole xml-commons-apis RHEL-6.0 akurtako xml-commons-resolver RHEL-6.0 patrickm but seems correct mharmsen : ldapjdk alee : jython akurtako : adaptx junit4 xml-commons-apis swagiaal : junit avalon-framework regexp libreadline-java jakarta-commons-codec jjohnstn : log4j bcel castor classpathx-jaf jzlib jakarta-commons-daemon jakarta-commons-httpclient jakarta-commons-pool jakarta-oro javacc caolanm : jcommon-serializer flute libbase libfonts libformula liblayout libloader librepository pentaho-libxml pentaho-reporting-flow-engine sac dbhole : sinjdoc ecj patrickm : xml-commons-resolver bea-stax java_cup jlex Most of the packages seems to be ok with pure java. What next? Are they OK with removing it midstream i.e. without recompilation? If so, then it should just be a matter of adding the Provides to OpenJDK and we're done. Running into bz1211995 and this bz causes ipa server to not install. And seeing in catalina.out: Apr 16, 2015 1:05:12 a.m. org.apache.catalina.users.MemoryUserDatabase open WARNING: Exception configuring digester to permit java encoding names in XML files. Only IANA encoding names will be supported. org.xml.sax.SAXNotSupportedException: http://apache.org/xml/features/allow-java-encodings at gnu.xml.stream.SAXParserFactory.setFeature(libgcj.so.10) at org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:556) at org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:391) at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:103) at org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:140) at javax.naming.spi.NamingManager.getObjectInstance(libgcj.so.10) at org.apache.naming.NamingContext.lookup(NamingContext.java:793) at org.apache.naming.NamingContext.lookup(NamingContext.java:140) at org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:113) at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:137) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:109) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:81) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.StandardServer.start(StandardServer.java:703) at org.apache.catalina.startup.Catalina.start(Catalina.java:593) at java.lang.reflect.Method.invoke(libgcj.so.10) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) Apr 16, 2015 1:05:12 a.m. org.apache.catalina.core.StandardService start INFO: Starting service Catalina Apr 16, 2015 1:05:12 a.m. org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/6.0.24 Apr 16, 2015 1:05:12 a.m. org.apache.catalina.startup.HostConfig deployDirectory INFO: Deploying web application directory ca Apr 16, 2015 1:05:13 a.m. org.apache.catalina.startup.TldConfig lifecycleEvent SEVERE: Error processing TLD files for context path /ca java.lang.IllegalArgumentException: URI "file:./" is not hierarchical at java.io.File.<init>(libgcj.so.10) at org.apache.catalina.startup.TldConfig.getJarPaths(TldConfig.java:636) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:305) at org.apache.catalina.startup.TldConfig.lifecycleEvent(TldConfig.java:688) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4616) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) The exception you have provided do not seem to be related to this bugzilla. What led you to pointing it here? This is cleanly packaging issue. The SAXNotSupportedException only happens when IPA was running with java-1.5.0-gcj, which was automatically pulled by one of IPA's dependencies. After switching to java-1.8.0-openjdk the exception no longer happens. In Comment #10 you suggested about adding java-gcj-compat to the list of provides. Is that still the plan? (In reply to Endi Sukma Dewata from comment #22) > The SAXNotSupportedException only happens when IPA was running with > java-1.5.0-gcj, which was automatically pulled by one of IPA's dependencies. > After switching to java-1.8.0-openjdk the exception no longer happens. > > In Comment #10 you suggested about adding java-gcj-compat to the list of > provides. Is that still the plan? Thanx for explanation. Then please, remove that requires, and correct "requires: java" So you will be aligned with system jdk. >
> Thanx for explanation. Then please, remove that requires, and correct
> "requires: java"
>
This is valid for all dependences. I already wrote to all maintainers, and got nearly no reply.
I bet, adding gcj-comapct-whatever will bring us all to troubles later.
Let me clarify, our own packages do not have direct dependency on java-gcj-compat, and in fact they cannot run with Java 1.5. They do require Java 1.6 or later, and we already have this dependency: Requires: java >= 1:1.6.0 I'm not sure if changing it to this will solve the problem: Requires: java The problem is the lower level dependencies still do require java-gcj-compat, so when we install our packages they will pull both gcj 1.5 and openjdk 1.8. Because of the priority, alternatives will pick gcj 1.5 over openjdk 1.8, and the installation fails because it cannot not run with Java 1.5. If we use alternatives to switch manually to openjdk 1.8 before installation, the installation will work just fine, but that also means the lower level dependencies that do require java-gcj-compat actually work just fine with openjdk 1.8. So I think the possible solutions are: 1. Add java-gcj-compat into openjdk's provides. As mentioned above, so far they work just fine. If someone really needs gcj they can always switch back using alternatives. 2. Change the alternatives' priority such that openjdk 1.8 is higher than gcj. 3. Remove openjdk 1.8 if it's considered "too new" to be usable. The openjdk 1.6 or 1.7 already have higher priority than gcj. 4. Add "Conflicts: java >= 1:1.8.0" into our packages. 5. Require users to switch to openjdk manually. 6. Automatically change the alternatives to use openjdk during installation and runtime. 7. Hard-code our packages to use certain openjdk version. I don't think options #4-7 are good practices in general. Thanks Endi. I don't think 'Requires: java' will work either. 'Requires: java-openjdk' that I mentioned in comment #25 could work, but then it will be limited to OpenJDK. I think option #2 (making OpenJDK8 priority higher than GCJ but lower than OpenJDK6) is the best approach here. Jiri, are you ok with the above? Looking to the specfiles:
gcj:
%define origin gcj%{gccsuffix}
%define priority 1500
jdk8
# priority must be 6 digits in total
%global priority 0000%{updatever}
Now, looking into https://bugzilla.redhat.com/show_bug.cgi?id=1189084
all *openj*jdks in rhel 6 are enforcing priority of 6.
So adding force to gcj to 4
keeping jdk 6 and 7 on
1{6,7}0XXX
and putting jdk8 to anything on 5 digits will do the job.
If acks appear here, I will push the changes to both jdk8 and gcj (the restriction)
Endi, thanx for bringing up solution with priorities. I would not thought it can help.
If GCJ is fixed, can we just not make JDK 1501 and leave gcj alone? The gcj rpm has been touched in years and I would prefer not to change it unless it is really needed. As you wish. Setting jdk8 to 1800 will do the job and will be more aligned with other jdks. My intention to touch gcj was to add the priority check so no one will accidentally rise length of that "number". If you are sure gj package wil not be touched, ten then the check is definitely not necessary and modification in jdk8 will be more then enough. One question - in 6.7/7.2 Are you going to keep the priorities of jdk8 below jdks 6 and 7? We lready provides java in 6.6/7.1. Or the priorities will get to normal once we provide also javac? Yeah unless there is a very serious issue in GCJ, I don't see us updating it.
1800 will not break other 1{6,7}0XXX priorities, right?
re: 6.7/7.2 -- it is late for 6.7, we can propose it for 6.8/7.2 though; I am fine with raising priority to higher than OpenJDK6 and 7.
the change was pushed and build is being build http://pkgs.devel.redhat.com/cgit/rpms/java-1.8.0-openjdk/commit/?h=rhel-6.7&id=f07e421351229ab7ca6b89028d2d65ba333e2ed2 http://brewweb.devel.redhat.com/brew/taskinfo?taskID=9070148 the change was pushed also to rhel 7.2 but no build done (yet, unrelated failure) > the change was pushed also to rhel 7.2 but no build done (yet, unrelated > failure) https://bugzilla.redhat.com/show_bug.cgi?id=1212540 http://download.devel.redhat.com/brewroot/work/tasks/94/9070094/build.log This bug is not fixed, however workaround is provided to remove all bad caused by this. The true fix will probably never go to rhel6 . I will move this bug to modified, but not sure if it is about to be ever closed. Hello. Myself and Mikolaj had made some research, and this is not possible to fix for rhel6 We are not able to get rid of dual gcj + openjdk + multiple versions of any java from rhel. Even worse. openjdk do not provide same libraries, as are expected when one is requiring gcj compact, so openjdk simply can not provide them. Luckily, this issue is not persisting in rhel7. |
Description of problem: java-1.5.0-gcj is LONG-since obsolete but it keeps getting included in tomcat6 installations because none of the new OpenJDK (and likely the -ibm and -oracle Java RPMs too) have been marked to provide the 'java-gcj-compat' feature. Version-Release number of selected component (if applicable): 1.7.0.71-2.5.3.1.el6 How reproducible: Steps to Reproduce: 1. rpm -q --whatprovides java-gcj-compat Actual results: java-1.5.0-gcj-1.5.0.0-29.1.el6.x86_64 Expected results: java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el6 or any of the other -{oracle,ibm} rpms of recent vintage Additional info: