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

Jiri Vanek jvanek at redhat.com
Thu Feb 26 15:24:16 UTC 2015

On 02/26/2015 04:20 PM, Robert Marcano wrote:
> 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.

The legacy jdk have not unvoulenteerly run this regular fedora-java stack code - never. Thats what 
those rules should achieve.

The usage should be for third party development/usage only.

>> === 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

More information about the devel mailing list