Excerpts from Ward, David - 0663 - MITLL's message of Thu Mar 03 22:36:40 +0100 2011:
> I know that people have asked in the past about removing gcj from Fedora
> in favor of OpenJDK, and I'm aware that this has not happened for
> reasons including architecture support on some platforms. I don't know
> when this was assessed last, but I'm leaving that question alone for now.
Actually we discussed this during our SIG meetings and recent changes
to Java packaging guidelines[1] reflect this. We are discouraging
building with GCJ support, but these guidelines are relatively new so
it will take some time for packages to be rebuilt with respect to new
guidelines. My guess is F-16, partially also F-15.
>
> The Java packages I have examined in Fedora 14 are forcibly built using
> gcj so that the AOT bits are included, which is fine. However, during
> the final stages of packaging, rpmbuild searches and finds the AOT bits,
> sees that they link against libgcj_bc.so.1, and automatically adds that
> as a dependency to the package. The packages should not, however,
> depend on libgcj -- they can be used as-is with OpenJDK or another JRE,
> simply ignoring the AOT bits. This is analogous to not requiring
> 'man-db' to be installed if a package contains man files, or not
> requiring 'gdb' to be installed if a package contains debug symbols.
> You can take advantage of those if you would like, but they are not
> required for use.
This is not completely true though. gcj is required for post/postun
scriptlets.
> So can we fix the rpmbuild macros so that the AOT bits are ignored when
> automatically adding dependencies?
We could, but time would be better spent actually fixing packages
still building with gcj. Feel free to file bugs against packages
building with gcj support. But please do so against rawhide. If anyone
gives you trouble point them to the guidelines :-) As always...working
patches against specs are best.
>
> Also on this topic, there is a macro in the SPEC file of a lot of the
> Java-based packages that doesn't work quite right:
>
> %define gcj_support
> %{?_with_gcj_support:1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?_without_gcj_support:%{?_gcj_support:%{_gcj_support}}%{!?_gcj_support:0}}}
>
> Somehow this always defines "gcj_support" as 1, even if I do "rpmbuild
> --without gcj_support". If I slightly alter the way the macro is
> written, then it seems to have the intended effect:
>
> %define gcj_support
> %{?_with_gcj_support:1}%{!?_with_gcj_support:%{?_without_gcj_support:0}%{!?_without_gcj_support:%{?_gcj_support}%{!?_gcj_support:0}}}
>
>
> Some packages additionally hard code this value, using one of these two
> lines:
>
> %define _with_gcj_support 1
>
> %define gcj_support 1
>
> Those lines needs to be removed wherever they appear. Fedora 14's
> rpmbuild macros set "_gcj_support" to 1, so this is the default if no
> options are given and the long macro above is included. A user ought to
> still be able to do "rpmbuild --without gcj_support" if they want,
> without having to edit the SPEC file.
Yes, these are ugly, non-working and hard to grok in the first
place. They'll be gone when gcj support is removed from spec...
>
> Thanks,
>
> David
Hope this answered your questions. If not, ask some more :-)
[1] https://fedoraproject.org/wiki/Packaging:Java#GCJ
--
Stanislav Ochotnicky <sochotnicky@xxxxxxxxxx>
Software Engineer - Base Operating Systems Brno
PGP: 7B087241
Red Hat Inc. http://cz.redhat.com
Attachment:
signature.asc
Description: PGP signature
-- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
