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 > pom.xml > 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 > http://fedoraproject.org/wiki/How_to_create_an_RPM_package > > This will include src.rpm, spec file, correct target architecture, and > dependencies, like in the Solr RPM at > https://bugzilla.redhat.com/show_bug.cgi?id=102590<https://bugzilla.redhat.com/show_bug.cgi?id=1025904> > Exactly. On downloading dist tar archive using above release URL is not generated <package>-<release>.tar.gz file but file with name only <release> (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. Tomasz -- 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 elasticsearch+unsubscr...@googlegroups.com. 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.
