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

Aleksandar Kurtakov akurtako at redhat.com
Thu Feb 26 08:19:24 UTC 2015


----- Original Message -----
> From: "Jiri Vanek" <jvanek at redhat.com>
> To: "Development discussions related to Fedora" <devel at 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 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.

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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


More information about the devel mailing list