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

Thu Feb 26 15:26:38 UTC 2015

----- Original Message -----
> From: "Robert Marcano" <robert at marcanoonline.com>
> To: devel at lists.fedoraproject.org
> Sent: Thursday, February 26, 2015 5:20:04 PM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java	platform in Fedora
> 
> On 02/24/2015 05:04 AM, Jaroslav Reznik wrote:
> > = Proposed System Wide Change: Legacy implementations of the Java platform
> > in
> > Fedora =
> > https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
> >
> > Change owner(s): Jiri Vanek <jvanek at redhat.com>
> >
> > Currently Fedora supports one main Java runtime and Java Development Kit
> > (JDK)
> > and from time to time one future JDK as a tech preview. This change should
> > be
> > set of rules, which will enable community to maintain legacy JDKs. Please
> > note, people are bugging main JDK maintainers pretty often with this, and
> > to
> > allow them to maintain legacy JDKs is a step in right direction.
> >
> > * This Change is announced after the Change Submission Deadline as an
> > exception to the process. May not be approved for proposed Fedora release.
> > *
> >
> > == Detailed Description ==
> > This is no real work proposal. The result of this proposal is set of rules,
> > which will allow community maintainers to pack any legacy jdk and will be
> > ensuring that this JDKs will not conflict by any other JDK and will
> > smoothly
> > integrate to system. The results are summarized here, and pledged for
> > discussion until final resolution is done.
> 
> I think for this to work, real work should be done by all Java
> packagers. There is no advantages of being able to install any community
> maintained legacy JDK if I can't use already packaged code. An example
> PostgreSQL JDBC driver is currently built with Java 8 bytecode level, it
> can't be used with any previous Java release. This happen because
> upstream developers frequently forget to add the --target javac command
> line argument for the minimum supported Java release they support (and
> work with upstream to add it). So a lot of packages need to be patched
> because they will target the built time Java bytecode level.

Now, this is the kind of work I would not do for my packages. There are 2 options for this to happen:
* Interested person becomes maintainer of the package and takes care of such patching. I'll happily give maintainership to any such person.
* Interested person fixes setting target upstream properly (note that this is double edged sword as target 1.5 would not work with Java 9 and requires keeping track). Once Fedora version is updated this would be fixed in Fedora.

Alexander Kurtakov
Red Hat Eclipse team

> 
> >
> > === Proposed rules ===
> > 0. '''Main JDK maintainers are not never ever responsible for any legacy
> > jdk.
> > This must remain clear'''
> >
> > ==== 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
> >   1. so from killed java-1.7.0-openjdk will become new package java-1.7.0-
> > openjdk-legacy
> >   2. next main jdk do Obsolete previous one as usually
> > 2. new package '''must''' not do any virtual provides (aka
> > java,java-devel)...
> > (protection against random pull by as dependence)
> >   1. it provides only itself by name
> > 3 its priority '''must''' be kept on less digits (right now it would be 5)
> > then main jdk (protection against winning in alternatives after update)
> >   1. the automated check as
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1189084
> > are '''mandatory'''
> > 4. at least one of the main-jdk's members '''must''' be set as comaintainer
> > (to watch the commits and save the world if necessary)
> > 5. new  package '''should''' to follow both original jdk (ideally not
> > change
> > at all (except source updates and necessary)) and current main jdk as close
> > as
> > possibly
> >   1. here it requires some common sense and a lot of testing if integration
> > with system is as expected
> > 6. as it is generally not new package, the review process '''should''' be
> > only
> > formal - to know maintainer and to create cvs repo
> >   1. this is quite important, otherwise the new maintainer can become
> >   really
> > frustrated, and we are forcing the "dead" package over"orpahned" so the
> > full
> > review (especially in alignment with rule 5) really should not be forced.
> >   2. on the contrary, rules agreed here '''must''' be checked.  (even the
> > number 5)
> > 7. all depending packages '''must''' keep requiring java-headless or java
> > (and
> > BuildRequires java-devel). Requirements on any exact jdk - or even worse on
> > any exact legacy jdk are forbidden and needs FESCO exception.
> >
> > This option is forcing maintainers to fight with the name x current setup
> > of
> > alternatives. However, the work should be minimal. But it makes the update
> > path pretty clear and it keeps users well protected against legacy jdk.
> >
> > ==== option two - orphaning legacy jdks and ensure update path ====
> > 1. main JDK is only orphaned when new main JDK landed
> >   1. it do '''not''' Obsolate previous jdk
> > 2. other rules (2-7) are same
> >
> > This is making life of legacy JDK maintainers a bit simpler. But I don't
> > know,
> > how to ensure proper "obsolete" implementation in this case.
> >
> > == Scope ==
> > * Proposal owners: are responsible for initial setup of those guidelines.
> > The FESCO, the owners and pssible legacy JDKs maintainers have to agree on
> > those rules. New legacy JDK can be then added anytime in Fedora lifecycle.
> > * Other developers: no developers
> > * Release engineering: in ideal case, no release engineer needed
> > * Policies and guidelines: The proposal may split to proposal and "Legacy
> > JDKs
> > in Fedora guidelines" pages
> > _______________________________________________
> > devel-announce mailing list
> > devel-announce at lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel-announce
> >
> 
> --
> 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