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.
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.
So can we fix the rpmbuild macros so that the AOT bits are ignored when automatically adding dependencies?
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.
Thanks,
David
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@redhat.com Software Engineer - Base Operating Systems Brno
PGP: 7B087241 Red Hat Inc. http://cz.redhat.com
On 09:37 Mon 07 Mar , Stanislav Ochotnicky wrote:
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.
There are some places where AOT is still needed e.g. ecj is much slower when not using AOT.
java-devel@lists.fedoraproject.org