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

[Jiri Vanek]

On 02/24/2015 05:21 PM, Mikolaj Izdebski wrote:
> On 02/24/2015 04:59 PM, Pete Travis wrote:
>> On Feb 24, 2015 8:32 AM, "Mikolaj Izdebski" <mizdebsk at redhat.com> wrote:
>>>
>>> On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
>>>>> 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

This pure theoretical work is based on various troubles various multiple/legacy jdks caused in last 
years.  So it is preventing the issues we know will rise.

>> needed.
>>>
>>> I fully agree with Alex here.
>>>
>>> I would add that if someone really wants to maintain older JDK in Fedora
>>> then it should up to *them* to come up with a solution that will work

Them? ANy packaging/openjdk newbie? Cool. It will break and will breaak a lot.

Those guidelines were written to protect fedora from possible harm.

>>> and satisfy expectations of JKD maintainers and Java SIG. Maintaining
>>> package is more than clicking "unorphan" in pkgdb.
>>>
>>> --
>>> --
>>>
>>
>> If some third party supplies 'java' as the $legacy jdk, and the user
>> installs a Fedora package built on $current jdk, which provider will win,
>> and what packages will break?
>

Hopefully none. And the guidelines should prevent any unsuitable jdk to "win" automatically.

> It's implementation detail of different package management systems
> (yum/dnf etc) and in general it's unspecfied. My experience shows that
> multiple packages providing the same thing are unreliable in practice
> and best avoided.
>
>> If the user uses alternatives to set the jdk (that applies here, right?)
>> any applications that need one version or the other could break?
>

I don't know how to avoid this issue. But at least it will happen - if happen at all - after the 
manual switch is done.

> Particular applications can be configured to use different JRE/JDK
> versions (for example you can run Maven with Java 8, but Ant with Java
> 7). Per-user configuration is also possible (user bob runs Maven with
> Java 8, but fred with Java 7). Fedora is quite flexible in this aspect.
>
> Moreover, Fedora can be configured not to use alternatives for Java
> apps, so you can have /usr/bin/java pointing to old JDK while Fedora
> applications are running with default (latest) JDK.
>
>> I understand these are relatively ignorant questions, but if the aim is to
>> provide a path for someone to maintain older JDKs it seems better to offer
>> them guidelines and best practices instead of "you'd better be competent
>> enough to figure it out".  They might not think of all the potential
>> conflicts.

Yes, this sounds right.
>
> If someone wants to maintain old JDK they are free to do so. Moreover,
> they will surely get help from Java SIG with implementing that, provided
> they show enough involvement. But IMO packaging guidelines is not a
What is an better place?

> place for listing details how compat packages for JDK should look like.
>

Java SIG is busy enough. Why to add you more work?

J.