----- Original Message -----
From: "Jiri Vanek" <jvanek(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)lists.fedoraproject.org>
Sent: Thursday, February 26, 2015 9:52:42 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in
Fedora
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(a)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.
As long as this happens in COPR repo until it's good to go I don't see a problem.
This will also means that at the time it goes into Fedora we do not speak about newbie
anymore.
Alexander Kurtakov
Red Hat Eclipse team
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.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct