- Package:
- icedtea-netx
- Source:
- icedtea-web
- Submitter:
- Jörg-Volker Peetz
- Date:
- 2019-11-24 22:15:03 UTC
- Severity:
- wishlist
Dear OpenJDK Team, why is the dependency list not expanded to "openjdk-8-jre | openjdk-7-jre | openjdk-6-jre" although the package already contains the files for openjdk-8? On my testing/sid system this would allow me to use openjdk-8 packages only. Regards, Jörg-Volker.
icedtea-netx can be used with any JRE. Java Network Launch Programs (jnlp) declare a specific version of JRE in the jnlp file, and often misbehave if another version is used. javaws prints a warning on stdout if the chosen JRE is not the one declared in the jnlp file, but it easy to miss it. In my case, I use a jnlp application once a year for tax filings, supplied by Italian tax authority Agenzia delle Entrate, via jnlp technology. It works correctly only with openjdk-8-jre, and being provisioned via jnlp, needs javaws from icedtea-netx. So, due to icedtea-netx dependency on default-jre I end up with 2 JRE installed: 8 and (currently) 11. The default JRE ends up being 11, so I have to configure icedea-netx to use the 8, and cannot remove 11. This is too much hassle and bloat to pay taxes :o) I would like to see this wishlist bug closed this way: - icedtea-web should depend on java-runtime, and suggest default-jre - openjdk-8-jre should provide java-runtime (it provides only versioned ones: java2-runtime, java5-runtime, java6-runtime, java7-runtime, java8-runtime) This would make it easy to have only openjdk-8-jre and icedtea-netx installed, without defaul-jre and its dependencies. As things stand, one must resort to other more complex options, like equivs to circumvent package dependencies, or simply tolerate the bloat. Regards Marco Gamberoni
Hello Marco, I agree about the hard dependency on default-jre. That's the reason that the javaX-runtime virtual dependencies were created. However, I'm not sure about creating a new java-runtime dependency, since I think that we're going to continue to have situations where we have to differentiate between JRE runtimes. Since the default-jre going back to oldstable provides java8-runtime, would it be okay to have icedtea-web depend on java8-runtime, which can be satisfied by default-jre for stretch and anything later? This should simplify your use case and continue to work until there is a default-jre that is for some reason unable to run older byte code. Cheers, tony
In data sabato 23 novembre 2019 19:36:03 CET, hai scritto: Hello Tony, no, I did not say so: my wish is icedtea-netx depend on _provided_ java-runtime. Icedtea-netx is a program written in java, so it depends on a java runtime to run. Its job is to download a java application described by a jnlp file that also declares some JRE version under which the downloaded app wants to run. While icedtea-netx must be compatible with any JRE, or it is its own bug, the downloaded app JRE requirement is out of Debian packaging control, is written in the jnlp file, and is icedtea-netx (javaws) business. So the ipotetical need to differentiate between JRE runtimes in the dependency list of icedtea-netx would be a bug in icedtea-netx. Would work, but is less clean: the virtual package java8-runtime would be recycled to convey the semantics of java-runtime (="any JRE"), just because currently (afaict) all available JRE packages provide java8-runtime; while, otoh, openjdk-8-jre does not provide java-runtime. But it should, shouldn't it? It seems to me, this is a packaging bug in openjdk-8-jre. It is not default-jre's duty to provide java8-runtime, it is up to the JRE package that is installed because default-jre depends on it. I would argue that default-jre should not have a "Provides:" field at all. - default-jre is a REAL PACKAGE, which pulls in the current version of a JRE. - java-runtime and java8-runtime and java[0-9]+-runtime are virtual packages - icedtea-netx runs with openjdk-8-jre and openjdk-11-jre. Due to its role, it has to run with any JRE, or it is a bug. My problem: install just any single JRE package _and_ icedtea-netx, nothing else. No default-jre and none of its dependencies wanted. My understanding of packaging logic is that to make this possible: - icedtea-netx should depend on java-runtime. - any package that installs a JRE should provide java-runtime Also, as Java Web Start technology has been deprecated by Oracle after Java 8, and support has been picked up as an open source project: https://openwebstart.com/ which is endorsed by icedtea-netx upstream https://github.com/AdoptOpenJDK/IcedTea-Web placing in default-jre a "suggest" to icedtea-netx seems a good thing. Following the changes in the upstream of the free implementation of Java Web Start technology has been difficult. A suggest (perhaps also a recommend) is good service to users. Thanks for listening,