On Wednesday, 5 March 2014 08:15:02 UTC, Jörg Prante wrote:
Tomasz, Elasticsearch source tarballs are available at github
https://github.com/elasticsearch/elasticsearch/releases and the RPM
should be automatically built, just by issuing the command "mvn install"
Correct me if I'm wrong. These archives are not official/signed dist files.
These are on-the-fly generated archives from release label. Isn't it?
For the RPM, I agree with you. I'm also disappointed by the RPM package
offer so far. It seems to me the ES team misunderstands RPM as a solely
binary distribution format, and used a simplified Maven RPM plugin build in
I'm really appreciated that someone is trying to help generate regular
packages but current approach seems is waste of time.
Different distributions are using different way of packaging. Sometimes are
using different init scripts templates.
Differences between OSes are even deeper.
For example on creare Solaris (IPS) packages current init scrips used by
pom.xml does not allow use service instances. Solaris service management
consist from two files: SMF service description file and SH backend script
which is completely different than rpm based Linux distributions.
pom.xml file creates package without proper dependencies (for example has
no java package dependency).
Instead storing in elasticsearch git tree shared objects (which is quite
strange) better would be document that this software needs/depends on sigar.
I have installed a RHEL7 Beta yesterday to start a rebuild of Elasticsearch
with Maven according to Fedora rules
This will include src.rpm, spec file, correct target architecture, and
dependencies, like in the Solr RPM at
On downloading dist tar archive using above release URL is not generated
-.tar.gz file but file with name only (lack of
proper tar.gz ext). So for example these URLs cannot be used in Source:
spec file field.
IMO it would be way better if ELK components will be distributed in real
dist source archives (best with official SHA checksums) and not as a git
substitutes which cannot be used straight (without additional operations)
as input files to create any type of packages.
Best will be if ELK developers will leave packaging layer to people with
proper packaging skills
All what is needed here it is proper official source tar ball
I can understand that currently available packages can be used on prepare
some kind of dirty POC but in the same time using such packages in real
production environments in many cases will be completely unacceptable.
You received this message because you are subscribed to the Google Groups "elasticsearch" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firstname.lastname@example.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/449ae0d0-f6a1-4bb7-841c-1bbbfdda5321%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.