...where java is no longer part of the flatpak-runtime. (At libreoffice flatpak
build time, the java-11-openjdk rpm will populate /etc/alternatives (even though
that is outside /app) with symlinks to /app/lib/jvm, so that the symlink chain
/app/lib/jvm/java -> /etc/alternatives/java_sdk/ ->
/app/lib/jvm/java-11-openjdk-11.0.9.11-9.module+f33+3+4101bf32.x86_64/ (or
whatever the latter's exact name) will work. But at flatpak composition time,
those non-/app files will be dropped from the resulting flatpak, so that
container.yaml needs to set up the /app/lib/jvm/jre-flatpak symlink for
--env=JAVA_HOME=/app/lib/jvm/jre-flatpak to find the Java installation under a
stable name, as then the /app/lib/jvm/jre -> /etc/alternatives/jre/ symlink will
be dangling.)
In combination with <https://src.fedoraproject.org/rpms/libreoffice/c/
3a744017d0590484b78b32e697b15af48d296838?branch=f32> "Resolves: rhbz#1900532
Adapt to Flatpak /app/share paths". While most data is in /app/share/hyphen,
/app/share/myspell, and /app/share/mythes, en_US.aff and en_US.dic are in
/usr/share/myspell, so needed to be symlinked to /app/share/myspell.
...if they used naming based on
id: org.libreoffice.LibreOffice
(Randomly picking just -writer for this experiment for now. Ultimately, the
various files should be massaged similar to what upstream
solenv/bin/assemble-flatpak.sh does for the Flathub builds.)
