Arch Linux User Repository

I am finding the same as @jettyscythe - I checked out the 8.8.1 commit and it works with the current ES version with --skipchecksum.

Secondly, this PKGBUILD works for the aarch64 architecture!

Thank you @HLFH for your work on this package.

I seem to be unable to install.

/home/jettscythe/.cache/yay/elasticsearch/PKGBUILD: line 40: cd: elasticsearch-8.9.0: No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...
 -> error making: elasticsearch-exit status 4
 -> Failed to install the following packages. Manual intervention is required:
elasticsearch - exit status 4

Beautiful. Ping me if anything somehow goes wrong.

@ipaqmaster Thanks. I updated the elasticsearch package and I cherry-picked your autoupdate custom script.
I added a systemd timer on my server to run it daily at midnight.

Let's not forget that Arch Linux is supporting officially the fork opensearch.
And that elasticsearch was orphan on the AUR until I took over.
I'm therefore not sure the whole phrasing about "critical component" and "timely manner" is relevant.
I was using elasticsearch with the Zammad open source help desk.
And I am now using it for my mail server with the dovecot-fts-elastic plugin to speed IMAP full-text search as otherwise, it is very slow.

That argument isn't good enough when this is a critical component of the Elastic Stack being left months out of date over and over again while the beats AURs have no trouble updating themselves in a timely manner. I guarantee users have run into issues installing this package with AUR helpers only to hit unexpected problems and realize it's not the same as the other Elastic Stack packages. Leaving out whether or not they care to sign up and click the out-of-date button on the site (Or even know it exists!)

You should at the very least have a pipeline configured to version bump AUR packages that you evidently aren't using yourself and I have a POC here which seems to be working well: https://github.com/ipaqmaster/elasticsearch-aur

This is a fork push of this AUR repository on my github with a new commit for your reference. I've tweaked the sources in PKGBUILD and .SRCINFO and added a script ./autoUpdate which checks Elastic's github for the latest Elasticsearch release and uses that for update detection.

When run - if it detects a new version the version references in PKGBUILD and .SRCINFO get updated with the b2sum before adding the files to get, setting a simple commit message and pushing the new version all automatically.

This solution leaves package maintenance in your hands so you would need to set up a cronjob somewhere that could run this check say, daily. Without missing schedule (Not powered down). I would also be comfortable being added as a co-maintainer and running this script on my own 24/7 hardware.

@ipaqmaster Well, when you flag a package out-of-date, I update it straight way on the same day. But, people forget to flag. And some like to complain without flagging the out-of-date state.

Regarding elasticsearch-bin, you can see it with @thorko as he is the maintainer of this other package.

Sure, feel free to use your custom packages :P

As said before, happy to use a reliant and proven method to update automatically AUR packages. Any detailed suggestions? EDIT: I enabled GitHub watch for releases email notification.

elasticsearch 8.9.0 released.

How are the other elastic AUR packages handling this differently where they're up to date in a short timespan but the elasticsearch and elasticsearch-bin AUR packages are always months out of date at a time?

The entire elastic project is infeasible to use on Archlinux given this ongoing desync and the beats agents and elasticsearch itself advise against mixing the versions when the connection establishes.

Could always chuck this .git onto a cicd pipeline to check for a new version and update the AUR package version var and checksums accordingly. It would be much better than cluster's falling apart over the beats sending new data formats to non-updated elasticsearch clusters every few months. In this recurring state the package just isn't reliable at all.

E: I'm putting together some bash lines to compare the stored version in the PKGBUILD and what git considers to be the latest release via api.github.com so it can check if a newer release is available and automatically update its checksums and fetch the latest tar.gz instead of using the version defined in the PKGBUILD

The choice made of the beats package was to have elasticsearch as an optdepend.
I won't go against the decision of the beats maintainer.
And it is true nowaways that the fork opensearch is more promoted by the Arch Linux community.

I will have a look at Renovate and other maintainer tools to automate the updates of this elasticsearch package.

If the maintainer of this package and beats are willing, this one could be deleted and added as a subpackage of beats.

Not sure why elasticsearch should be a subpackage of beats.

That was assuming this statement is accurate: "They're supposed to be a suite but I often run into issues with this package falling behind."

Updating a single pkgbase would update all subpackages simultaneously.