I do not wish to run elasticsearch on oracle-jre because of license issues. I see that the elasticsearch ebuild depends on virtual/jre, which itself depends on oracle-jre. Would it be possible for elasticsearch not to depend on oracle-jre? It will certainly work on icedtea: https://www.elastic.co/support/matrix#show_jvm
*** Bug 580008 has been marked as a duplicate of this bug. ***
I am clueless. After a portage sync: I removed all jres, made a depclean. Now virtual/jre pulls icedtea-bin when the oracle ones are masked. Elasticsearch doesn't pull orcles jre. ??
I'll close this one, sine everything seems to work now.
Reopening because I believe there is an issue here and you avoided it by emerging virtual/jre directly. I'll need to verify this tomorrow when I'm not half asleep but I'm guessing that this is because of the way elasticsearch has specified the dependency. RDEPEND="|| ( virtual/jre:1.8 virtual/jre:1.7 )" This is bad. It should be... RDEPEND=">=virtual/jre-1.7" I keep seeing non-Java people do this, probably because of unhelpful messages from repoman. I have already decided to overhaul the Java stuff in repoman to prevent this. In theory, it shouldn't make any difference but Portage has trouble working out the path of least resistance. Are you on a stable system? My guess is you have added elasticsearch as ~amd64 in package.accept_keywords and it's trying to find a stable JVM to satisfy the dependency. We haven't marked icedtea-bin:8 stable yet (will do soon) but instead of realising that icedtea-bin:7 would suffice, it picks oracle-jdk-bin:1.8 because that is stable. There is already a bug report about this problem.
I am running unstable amd64. The latest elasticsearch does run perfectly with icedtea, installation on a fresh system hasn't pulled oracles jre, when icedtea was installed first. It seems, the problem is long gone by now.
Okay. I'd still like to improve repoman but that is a wider issue.
