Fix flatpak builds (catering for their uncompressed manual pages)
Merge Request Required Information
Summary of Changes
...see (https://docs.fedoraproject.org/en-US/flatpak/troubleshooting/#_uncompressed_manual_pages) for details
Fix flatpak builds after 19065a8b01585a1aa5f22e38e99fc0c47c597074 "Temporarily move x86 to use Zero in order to get a working build":
When building the
if ${run_bootstrap} ; then
branch for suffix='' and loop='-main', the second
buildjdk ${builddir} $(pwd)/${bootinstalldir}/images/%{jdkimage} "${maketargets}" ${debugbuild} ${link_opt}
uses the JDK ($(pwd)/${bootinstalldir}/images/%{jdkimage}
) from the installjdk
on the previous line. But installjdk does
rm ${imagepath}/lib/tzdb.dat ln -s %{_datadir}/javazi-1.8/tzdb.dat ${imagepath}/lib/tzdb.dat
which made that JDK's tzdb.dat link to /app/share/javazi-1.8/tzdb.dat in a flatpak build (rather than the usual /usr/share/javazi-1.8/tzdb.dat in a non-flatpak build) which is not present at build-time (but will be present at runtime in at least the LibreOffice flatpak, which bundles tzdata-java built for the flatpak /app prefix). So using that JDK's compiler during the build kept failing due to java.io.FileNotFoundException for its lib/tzdb.dat.
(This was not an issue prior to 19065a8b01585a1aa5f22e38e99fc0c47c597074, as installjdk's modification of lib/tzdb.dat used to be done only for the "Final setup on the main image" at the very end of the build, not during the build for JDKs that are themselves used later during the build.)
The easiest workaround for this issue appears to be to just not bootstrap_build in the flatpak case, avoiding the situation that a JDK whose lib/tzdb.dat has been modified through installjdk is used during the build.
Approved Bugzilla Ticket
All submissions to CentOS Stream must reference an approved ticket in Red Hat Bugzilla. Please follow the CentOS Stream contribution documentation for how to file this ticket and have it approved.
- Resolves: rhbz#2102726