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

Jiri Vanek jvanek at redhat.com
Fri Feb 27 09:10:36 UTC 2015


On 02/26/2015 04:26 PM, Aleksandar Kurtakov wrote:
> ----- 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.

This should be out of scope. Nothing of javastack should be
allowed to use use legacy jdk - see rule 7. Togehter with rule 2 it should prevent this happening.
>
> 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



More information about the devel mailing list