Harden the Dockerfile build steps (LibreOffice symlink, shell error mode, checksum format)

Problem

While reviewing the Docker Official Images pull request that publishes XWiki 18.6.0 (docker-library/official-images#21937), the Docker Official Images maintainer made three suggestions about the Dockerfile we generate. None of them is a bug a user can hit today, but the first one turns a silent runtime failure into a build failure, and the other two align the file with the shell conventions used across the official images.

1. The LibreOffice symlink is resolved through an unquoted glob, and is never verified

The LibreOffice installation step ends with:

ln -fs $(ls -d /opt/libreoffice*) /opt/libreoffice

Two issues:

• The command substitution is unquoted, so word splitting would break the ln invocation should the glob ever match more than one path.
• More importantly, nothing verifies that the symlink actually points at a LibreOffice installation. That symlink is what XWiki (through JODConverter) probes to locate LibreOffice automatically, so if it ends up pointing at the wrong place the image still builds fine and office import/export silently fails at runtime.

The install directory can be derived from the pinned version instead of being discovered on the filesystem: the Document Foundation packages install into /opt/libreoffice<major>.<minor>/, and the updateLibreOffice Gradle task only ever writes a three-component version, so stripping the patch component always yields the right directory. Verifying the result in the same step makes a wrong installation fail the build.

2. The RUN blocks rely on exit-code chaining rather than an explicit error mode

The RUN blocks chain their commands with &&. The Docker Official Images convention is set -eux; with ; separators. Beyond being the house style, it is more robust to later edits: with && chaining, adding a line and forgetting its trailing && silently ignores that command's failure, whereas set -e always propagates it. set -x also traces each command in the build log, which helps when a build fails on one of the transient network errors these downloads are prone to.

3. The sha256 verifications do not use the conventional binary-mode format

The checksum verifications are written as:

echo "$SHA256 file" | sha256sum -c -

The conventional form for verifying a downloaded binary prefixes the filename with * and passes --strict, which makes sha256sum reject a malformed input line rather than skip it.

Proposal

Apply the three changes to template/Dockerfile and regenerate. For consistency, apply points 2 and 3 to every RUN block and every checksum verification in the file rather than only to the two blocks quoted in the review, so that the Dockerfile does not end up with mixed styles.