Going back to IcedTea, openjdk8 is obsolete

Jacek Konieczny jajcus at jajcus.net
Mon Jun 5 10:08:04 CEST 2017


On 2017-06-05 09:52, Tomasz Pala wrote:
> On Mon, Jun 05, 2017 at 08:46:36 +0200, Jacek Konieczny wrote:
>
>>> /usr/lib64/jvm/java -> icedtea8-3.4.0 symlink is provided by icedtea8-jdk
>>> - this package contains symlinks and manuals only, BUT also:
>>>
>>> Requires:       icedtea8-jar = 3.4.0-1, icedtea8-jdk-base = 3.4.0-1
>>> 		one symlink and 2 mans, ...20 MB of unnecessary stuff
>>
>> The Requires are the main part of this package ? as it brings all the
>> stuff together to make the complete 'JDK'.
>
> So (assumink JDK means Development Kit) the directory is not a part of
> JDK and should be moved somewhere outside. Consider what's the purpose of
> splitting icedtea8-jdk from icedtea8-jdk-base then.

You can have icedtea8-jdk-base, icedtea7-jdk-base and 
oracle-java-jdk-base installed at the same time – all of them would be 
fully usable provided you use their actual paths (e.g. 
/usr/lib64/jvm/icedtea8-3.4.0/jre/bin/java).

Then you can install single 'jdk' package, which includes symlinks so 
the binaries and libraries are available at the generic path.

>> The library is a part of the JRE. I guess we could move the
>> %{_libdir}/jvm/java symlink to icedtea8-jre, but it still needs to pull
>> whole JRE (that is still less than JDK).
>
> Yes, something like icedtea8-jre (with R: icedtea8-jre-base itself) should
> be used to system-select the JRE to be used.

Yes, that was the idea.

>> The symlink is there to allow multiple JDK/JRE versions installed (Java
>> world is crazy and one may need that) ? the symlink points to the
>> current default one.
>
> Moreover, we should have sth like oracle-jre package with appropriate
> symlink and fake provides for the systems with self-installed Oracle
> non-distributables.

Yes. The Sun and then Oracle Java used to be packaged that way. I have 
not been maintaining or using those any more so I don't know if this is 
still the case or if it has degraded somehow.

Jacek


More information about the pld-devel-en mailing list