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): libgcj-4.0.0-0.38 How reproducible: Every time Steps to Reproduce: 1. rpm -q --provides libgcj Actual results: lib-gnu-java-awt-peer-gtk.so.6 libgcj.so.6 libgcj4 libgij.so.6 libjawt.so.6 libgcj = 4.0.0-0.38 Expected results: The above plus jaxp_parser_impl Additional info:
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 libgcj.
OK, I've added: Provides: jaxp_parser_impl to java-gcj-compat. This will land in Rawhide tomorrow, closing.