F22 System Wide Change: Legacy implementations of the Java platform in Fedora

[Mikolaj Izdebski]

On 02/24/2015 01:34 PM, Severin Gehwolf wrote:
> On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
> [...]
>>> ==== option one - introducing new packages - preferred ====
>>> 1. main jdk is proclaimed as dead as it was until now.  The new jdk is derived 
>>> as new package prviousName-legacy
>>
>> Fedora already supports multiple JDKs installable in parallel. This was
>> inherited from JPackage project. This breaks long-established rule of
>> naming JDK packages as "java-x.y.z-vendor" used across different
>> distributions (JPackage, Fedora, RHEL, SUSE, ...)
> [...]
> 
> The idea behind this "-legacy" suffix was to ensure a reasonable upgrade
> path for people *only* using default java-x.y.z-openjdk package. 
> 
> Consider the following scenario (all hypothetical, not saying that any
> Fedora releases and JDK releases align in this way):
> 
> F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
> java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
> The upgrade from F22 => F23 will install java-1.9.0-openjdk and remove
> java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
> java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
> that no old JDKs stick around on the majority of Fedora systems.
> 
> If the name was kept there does not seem to be a good way to:
> 1.) Ensure dist upgrades update JDK packages

That should be possible to achieve without renaming JDK packages. I
haven't considered all options, but one of several possibilities is
creating "java" package that would require the latest JDK/JRE. If user
installs "java" then it will be updated to latest version when it
becomes available, but if user installs "java-1.8.0-openjdk" then it
won't be updated as user explicitly asked for 1.8.0.

> 2.) Ensure dist upgrades remove old JDK package (which may no longer
>     get security updates).

Firstly, as I understand upgrade isn't supposed to remove packages by
default, unless they are obsoleted or conflict with something. Are you
saying that JDKs should be treated exceptionally by package management
systems?

Secondly, if the old JDK is still maintained by someone then I don't see
a problem with leaving it installed - it shouldn't be used by default
unless user explicitly configured it as default. This is standard
behavior of PMS and at least that's what I would expect as user. (If old
JDK is not maintained any longer then it would be obsoleted and removed
during update.)

> Do you see a way to achieve this without a name change of the package?

I see some ways to achieve 1) without 2), but I don't think that 2) is
necessary or expected by users.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk