[Bug 288653] textproc/elasticsearch8: Update to recent version

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288653

--- Comment #43 from Saro <web@saromedia.com> ---
Last night, I realized my reply above may have given the wrong impression or
message. My point was to highlight the fact people need to be aware of the
port's origin, and perhaps this was a factor of not accepting my work in the
first place (which is understandable). I'm also inferring this based on Kurt's
comment to create a traditional port, which honestly is the right approach from
a security standpoint.

To be clear, I don't mind hosting the project and being responsible of the
distribution. I just don't know what the policy is with the ports tree, but I
trust port maintainers/committers have sound judgement in these types of
situations.

Now that is out of the way, some bad news: we may have no choice but to go with
an external building process. My modifications (re: removing code referencing
deprecated JDKs) unknowingly nerfed support for running ES on JDK 25. This
applies for both 8.19 and 9.x branches. There is no way around this.

This leaves us with the following possible options to get this port finally
committed:

1. Reinstate the deprecated JDK ports by begging portmgr. This solves our
dilemma, but is unlikely to happen.

2. Modify the port Makefile to download/bootstrap the missing JDKs as part of
the ES build process. This will add another layer of complexity, not to mention
longer build times. I honestly don't want to do this.

3. Have another host/service (e.g. GitHub Actions) build the distribution. This
is the simplest solution, and avoids having to upload dependencies separately,
thus removing the additional burden on committers.

This leads me to propose a solution to may satisfy the trust requirement with
option #3:

If I modify the GitHub Action to announce a SHA256 checksum after building the
distribution and before uploading the release artifact, is that an acceptable
form of verification? This allows the committer to triple check the release,
from source code to the final tarball.

The workflow is here:
https://github.com/portsbuild/elasticsearch/blob/freebsd/.github/workflows/gradle-package.yml

Logs: https://github.com/portsbuild/elasticsearch/actions

If anyone else has ideas, please do share as I feel like I've exhausted all
possible options. Apologies for the long wall of text.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.