You are of course correct, I've replaced the java-runtime dep with -headless. We can't really do much about the deprecation message, upstream wants you to use their bundled jdk (and nodejs) to ease their support system. However this sounds like a security nightmare to me, if I fix a CVE of the system jdk I expect it to be fixed in all java applications – same for the node packages.
Regarding the elasic packages: I agree. Additionally, there are already elasticsearch-xpack and kibana-xpack packages in the AUR. Is this something we should announce (on the Arch Announce mailing list)? Also, regarding the beats packages – even if we provide beats-oss on a fixed version (which also won't receive security updates) we will just have a bunch of packages marked as "out-of-date". Sounds like something for the AUR. On Sat, 1 Jan 2022 22:07:11 +0100 Pierre Schmitz via arch-dev-public <arch-dev-public@lists.archlinux.org> wrote: > Thanks a lot for your work! I already managed to migrate to OpenSearch > without major issues. > > I am a little confused about the java dependency. It requires > java-runtime instead of java-runtime-headless as Elasticsearch did. > However on launch I get the following warning: "no-jdk distributions > that do not bundle a JDK are deprecated and will be removed in a > future release". > > About Elasticsearch packages: As I understand it, we are not allowed > to distribute anything newer than version 7.10. This version is no > longer supported by upstream, right? So we wont get any (security) > updates. In that case we should rather remvoe these packages and ask > people to migrate to OpenSearch. > > Greetings, > > Pierre > > On Fri, Dec 31, 2021 at 5:39 PM Justin Kromlinger via arch-dev-public > <arch-dev-public@lists.archlinux.org> wrote: > > > > Hello everyone, > > > > As mentioned in a previous mail [0] I've taken some time to bring the > > ElasticSearch fork > > OpenSearch to Community [1]. > > > > I've also added twelve plugin packages, a package for the Kibana fork > > OpenSearch Dashboards and > > eight plugin packages for that. Additionally I packaged the opensearch-cli > > Go binary which > > currently conflicts with the opensearch package. More plugins will follow, > > but most of them can > > be installed manually as well (f.e. ingest-attachment). > > > > I've tested both opensearch and opensearch-dashboards with my old node > > data, but some plugins > > are untested because I have no experience with them (primarily the security > > plugin), so I would > > be happy if someone could test them out. > > > > Please note that opensearch doesn't use the upstream-included JRE and > > opensearch-dashboards > > doesn't use the upstream-included NodeJS but the ones provided by our > > repositories. Please keep > > that in mind for any bug reports towards upstream. > > > > This brings up the elastic-question: What should we do with the > > elasticsearch and kibana > > packages? If we keep them, someone would need to adopt them - I will orphan > > them since I won't > > be using them anymore. Do we want to update them to their newest version > > with the new Elastic > > license? Or drop them to the AUR? > > > > If we update them to a newer version the beats packages versions are > > complicated as well. The > > 7.X versions already need additional configuration in opensearch and > > versions >=7.13 won't work > > at all [2]. I would recommend new packages for the beats-oss version 7.12.1 > > or even 7.10.2 as > > recommended by opensearch. > > > > Euch einen guten Rutsch ins neue Jahr or a Happy New Year, > > hashworks > > > > [0] > > https://lists.archlinux.org/pipermail/arch-dev-public/2021-August/030496.html > > [1] https://archlinux.org/packages/?sort=&q=opensearch > > [2] > > https://opensearch.org/docs/latest/clients/agents-and-ingestion-tools/index/ > > > > -- > > hashworks > > > > Web https://hashworks.net > > Public Key 0x4FE7F4FEAC8EBE67 > > > -- hashworks Web https://hashworks.net Public Key 0x4FE7F4FEAC8EBE67
pgpUcIH5e89Nn.pgp
Description: OpenPGP digital signature
