Changed Java dependency from Depends to Suggest for Debian.

[webpatser]

Since people are also using the Oracle JAVA distribution and not the OpenJDK.

Now the installation will at least continue, and it will not give dependency errors when installing other packages after the installation of ElasticSearch.

[kimchy]

+1, I think it makes sense, @spinscale what do you think?

[spinscale]

I like it. I'll get it in

[spinscale]

Thanks a lot for your contribution! If you have any other recommendations about packaging, feel free to drop me a mail or create other github issues. Happy for any feedback!

Pushed into master at 9f43814

[kimchy]

@spinscale I think it makes sense to back port this to 0.90 as well, what do you think?

[spinscale]

@kimchy pushed it as well into 0.90

[ctrochalakis]

Actually, there is a big problem with that.

After installing the 0.90.2 package the whole jre was removed. Since no package depends on the jre anymore, apt decides to remove it!

$ aptitude install elasticsearch
The following packages will be REMOVED:    
  ca-certificates-java{u} java-common{u} openjdk-7-jre-headless{u} openjdk-7-jre-lib{u} tzdata-java{u} 
The following packages will be upgraded:
  elasticsearch 

Since elasticsearch obviously depends on java it should be stated as a dependency. The only oracle java package i found (https://launchpad.net/~webupd8team/+archive/java) correctly provides java*-runtime that is required by elasticsearch so this shouldn't be an issue.

We shouldn't break packaging for those who install oracle java by hand. Those users could "trick" apt by installing a dummy package that satisfies the dependency. This can by done with equivs.

apt-get install equivs
equivs-control oracle-java-dummy
vim oracle-java-dummy (modify Package name, and add a Provides: java7-runtime line)
equivs-build oracle-java-dummy
dpkg -i oracle-java-dummy*deb

[spinscale]

This sounds like an issue to fix, I'll check it out.

@webpatser do you agree or see another solution to this?

[webpatser]

Sure. If there is no other way.. Maybe add it to the debian installation how to?

[webpatser]

http://www.debian.org/doc/debian-policy/ch-relationships.html

Maybe the Enhances flag is better then? Reading the description it should not remove the java packages if present "This field is similar to Suggests but works in the opposite direction. It is used to declare that a package can enhance the functionality of another package."..

(but then again, suggest also doesn't mention this auto-removal)..

[ctrochalakis]

I don't think that enhances will solve the auto removal issue. It is also not appropriate because it states that elasticsearch enhances java's functionality which is not the case.

Personally I think the equivs solution is the "correct way" to handle such cases. To make it easier you could provide a java-dummy package from the elasticsearch download page.

[spinscale]

@ctrochalakis I was not yet able to get to the status with apitude like you reached above. Are you using ubuntu as well? Which packages did you delete beforehand in order to get this error?

Apart from that I am also coming to the conclusion that neither Enhances nor Recommends is a good match, after reading the package guidelines.. so the equivs solution might be the best one.

[webpatser]

You can also just have no dependency set. I will complain about JAVA when it's not present during startup... Maybe provide a 'apt-get install java..' message in the init script.

[ctrochalakis]

@spinscale Sorry for taking so long to answer. Here are the steps to reproduce the java removal behaviour:

# First install an elasticsearch that depends on java
$ sudo apt-get install elasticsearch=0.19.8
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  ca-certificates-java java-common openjdk-7-jre-headless openjdk-7-jre-lib tzdata-java
Suggested packages:
  default-jre libnss-mdns sun-java6-fonts fonts-ipafont-gothic fonts-ipafont-mincho ttf-wqy-microhei ttf-wqy-zenhei ttf-indic-fonts
Recommended packages:
  icedtea-7-jre-jamvm
The following NEW packages will be installed:
  ca-certificates-java elasticsearch java-common openjdk-7-jre-headless openjdk-7-jre-lib tzdata-java
0 upgraded, 6 newly installed, 0 to remove and 7 not upgraded.
Need to get 0 B/54.6 MB of archives.
After this operation, 72.0 MB of additional disk space will be used.
Do you want to continue [Y/n]?

....

# Try to update with the latest version (uses suggests) and java gets removed
$ aptitude install elasticsearch
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
luke ~ sudo aptitude install elasticsearch
The following packages will be REMOVED:
  ca-certificates-java{u} java-common{u} openjdk-7-jre-headless{u} openjdk-7-jre-lib{u} tzdata-java{u}
The following packages will be upgraded:
  elasticsearch
1 packages upgraded, 0 newly installed, 5 to remove and 7 not upgraded.
Need to get 0 B/17.1 MB of archives. After unpacking 52.1 MB will be freed.
Do you want to continue? [Y/n/?]

[paravoid]

I concur with @ctrochalakis. Enhances is definitely very wrong for this, and Suggests is also wrong and can result into apt doing the wrong thing because of a misstated dependency, as it has already been the case for some people. (I'm a Debian Developer).

These are Debian packages; coexisting with locally-installed Java defeats the purpose of that. If people really want to install Java locally instead of using make-jpkg or the PPA, they can either use equivs or not use the Elasticsearch .deb at all.

Moreover, on issue #3286 it has been mentioned that Elasticsearch is going to provide an apt repository. When that arrives, "apt-get install elasticsearch" should do the right thing and pull the JRE in, instead of just providing a broken package until the sysadmin installs it manually.

[spinscale]

Hey

Enhances and Suggests have been removed quite some time ago - did you see it somewhere in our current packages and this is why you bring it up again? If so, lets try to fix it ASAP, as I agree we should not use them.

We are preparing repositories, which will not include a java distribution. Yet, at the same time, we want people to use the newest java version available and preferrably the oracle JDK at the moment. As there problems with having those available (especially having an up-to-date JDK when using the stable debian release and of course the licensing issues for the oracle one) and we do not want people to use equivs, we decided to go this way.

We still warn people in the init script if no JDK exists and show how to install the oracle JDK using apt-get on the documentation.

You still think, that this is not sufficient to provide a good user experience under the given circumstances or that it is not the debian way? Interested in opinions here.

[paravoid]

I didn't see either of the two, I brought it up because right now there's no dependency whatsoever and none of these two alternatives sounded appealing either.

Honestly, I think that a Depends at the virtual package provides the best user experience. But, obviously, I'm a bit biased. I'd also wouldn't use the Oracle JDK either, so I guess I'm doubly biased :) This is off-topic, but why are you recommending that, if I may ask? It should matter less with OpenJDK 7 onwards, no?

In any case, most admins that care about a .deb for ElasticSearch would care about a .deb for the JDK as well — on the flip side, I can't imagine why someone would install Java by hand, but wouldn't do the same for Elasticsearch.

Besides the OpenJDK, Debian stable provides the "java-package" package for working with Oracle Java (apt-get install java-package; make-jpkg <tarball>; dpkg -i oracle-java7-jre*deb), and many Ubuntu users use the installer packages from the webupd8team PPA. Both of these provide the right virtual packages that would satisfy the dependency, so I think that a proper Depends: line + the recommendation of those two should be enough for the "installing in Debian/Ubuntu" section of the install guide.

[spinscale]

Offtopic answer: Yes, matters less with OpenJDK7, but it is not yet completely gone.

Ontopic answer: Actually, it is exactly opposite from our experiences in the fields. Admins care a lot about having a special version of the JDK installed and available and care less about this being a debian package or not (especially in times of puppet/chef automation). A part of the reason for this lies in elasticsearch itself: You have to have the same java version installed, not only between all nodes of an elasticsearch cluster (which most likely runs the same OS anyway), but also between clients, if you use the java API (as the JDK folks tend to change serialization of objects between minor releases). This means, that even across operating system boundaries you want to have the same java version down to the minor version.

Java does not have init scripts or needs log file configurations, it is just binary - the elasticsearch debian package comes with these included. So yes, there is a difference between having elasticsearch as a package compared to java.

Didnt know the make-jpkg trick, should add that to our docs.

[nik9000]

Offtopic answer: Yes, matters less with OpenJDK7, but it is not yet completely gone.

That last I heard on the mailing list was that this is gone now. If it is isn't it needs to be. All the problems with the OpenJDK need to be filed as issues, tags, and linked prominently somewhere. I'd be happy to contribute fixes if I knew what was broken.

Ontopic answer:...

Elasticsearch has a tradition of installing cleanly and working reasonably well without tuning. Installing the deb package and not getting Java is somewhat against that. In my ideal world it'd install Java and we'd tell folks if they wanted a specific version of Java then to make-jpkg, run your own apt repository with the version of java you want, or don't use the deb.

As far as the specific JDK version thing, that is really an argument against using any sort of Java serialization in the Java api. We are going to want to do rolling restarts to upgrade the JDK and I don't want Elasticsearch to blow up when I do it.