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

Jiri Vanek jvanek at redhat.com
Tue Feb 24 13:28:58 UTC 2015


On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
> ----- Original Message -----
>> From: "Jiri Vanek" <jvanek at redhat.com>
>> To: devel at lists.fedoraproject.org
>> Sent: Tuesday, February 24, 2015 3:02:38 PM
>> Subject: Re: F22 System Wide Change: Legacy implementations of the Java	platform in Fedora
>>
>> On 02/24/2015 01:50 PM, Dominik 'Rathann' Mierzejewski wrote:
>>> On Tuesday, 24 February 2015 at 13:34, 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
>>>> 2.) Ensure dist upgrades remove old JDK package (which may no longer
>>>>       get security updates).
>>>>
>>>> Do you see a way to achieve this without a name change of the package?
>>>
>>> Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk
>>> are different packages?
>>
>> yes they are, but the secon *is* update of first.
>>>
>>> If there are any packages requiring java-1.8.0-openjdk they can keep
>>> using it as long as it has a maintainer. java-1.9.0-openjdk will be
>>> a completely new package.
>>
>> Yes they can. But until now it was really bad idea.
>>
>> IcedTea-Web was also wrong example - it is requiring *main* jdk. Nothing
>> else.
>>
>> And as it is not strightforward to compile ITW agains different jdks, then
>> the strict rule have sense.
>>>
>>> I agree with MikoĊ‚aj that there's no need for what you're proposing.
>>>
>>
>> There is.  Not using those rules will completly break fedaora+java as we know
>> it now.
>>
>> I would much rather live without any legacy jdk, and if so then without any
>> rules. But not setting
>> them will bring chaos for majority of users.
>
> I have a question: Is there anybody that stepped in to maintain the legacy jdk?
> If there is nobody to maintain it trying to come up with this guidelines now would be pointless.
> In short I think that such guidelines would better be created *only* when there are interested parties, jointly with them and the process is played a bit by some copr repo or similar. Purely theoretical work is not needed.
>
There were several attempts in past like "can you please support jdk 7,6...in newer fedoras" and we 
always told no. When come speech about "do it on your own" suddenly many questions marks raised up.

The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to 
maintain it.

So deciding that legacy jdks are not never ever supportable, is also option.
Then we will move all users to that statement, and we will let them do theirs builds in copr...

Yes its possibility. It is actually the simplest one, but maybe not the generally desired one.


J.






More information about the devel mailing list