Red Hat Bugzilla – Bug 153684
libgcj should Provide jaxp_parser_impl
Last modified: 2007-11-30 17:11:03 EST
Description of problem:
The libgcj rpm should be listed as Providing jaxp_parser_impl, because it
contains gnujaxp. Otherwise yum will presumably unnecessarily look for an
alternative jaxp implementation.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rpm -q --provides libgcj
libgcj = 4.0.0-0.38
The above plus
This is tricky because some packages require specific
jaxp parser implementations. This generic virtual provides comes from JPackage
and I'm not sure it's a good idea. I think we should change packages that
require xalan and xerces to explicitly require them. And we should maybe create
a "sdk_jaxp_parser" virtual provide for packages that want to explicitly require
the built-in parser implementation.
I think jaxp_parser_impl is useful for dependencies for packages which don't
care which implementation of jaxp they use.
True. Another possibility is that I could add this Provides to java-gcj-compat.
Gary, what are the implications of doing this for packages that need xerces/xalan?
I'm not sure. Applications that use xerces make sure that xerces is the XML
parser by having xerces-j2.jar in the classpath; there's a bunch of files in
that jar's META-INF/services directory that point to various classes that are
loaded by reflection. How are libgcj's classes discovered? libgcj.jar doesn't
contain the META-INF/services stuff, so I'm guessing that libgcj's stuff is
loaded as a default when nothing else is found. If that's the case then it
shouldn't be a problem.
Also I think java-gcj-compat is a better place for the alternatives stuff than
OK, I've added:
to java-gcj-compat. This will land in Rawhide tomorrow, closing.