F22 System Wide Change: Legacy implementations of the Java platform in Fedora
akurtako at redhat.com
Wed Feb 25 09:40:36 UTC 2015
----- Original Message -----
> From: "Mikolaj Izdebski" <mizdebsk at redhat.com>
> To: devel at lists.fedoraproject.org
> Sent: Wednesday, February 25, 2015 11:14:35 AM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java platform in Fedora
> On 02/24/2015 04:06 PM, Jiri Vanek wrote:
> > On 02/24/2015 04:03 PM, Mikolaj Izdebski wrote:
> >> On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote:
> >>>> 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?
> >> I should add that user can easily remove packages which were installed
> >> as dependencies, but which are no longer needed by running "yum
> >> autoremove" command.
> > So by other words - from option "one" and "two" you vote for two, no
> > renaming, and removing rules 4,5,6,7.
> Technically I'm against this change, see my first post.
> > You do not complain about rule 2 and 3.Right?
> Rule 2 is definitely a good thing. Muliple providers of the same thing
> don't work in practice, so we should have only one package providing
> "java" etc.
> I don't know the exact scheme used for priorites, so I can't comment on
> rule 3. I trust you to set priorities correctly so that "main JDK" has
> highest priority. Lecacy and tech-preview JDKs should IMO have lower
I would even say that legacy(even any) JVMs should not use the alternatives system at all. I still remember the fun of having kaffe, jamvm, gcj.. with their own priorities, alternatives (java/javac/jar..) going out of sync and etc. This was a nightmare to support and it was causing more damage than helping. Using legacy JVM should be done using the tools that provide more isolation nowadays like scl to prevent these problems.
Red Hat Eclipse team
> Mikolaj Izdebski
> Software Engineer, Red Hat
> IRC: mizdebsk
> devel mailing list
> devel at lists.fedoraproject.org
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
More information about the devel