F22 System Wide Change: Legacy implementations of the Java platform in Fedora
jvanek at redhat.com
Fri Feb 27 09:43:53 UTC 2015
On 02/26/2015 02:51 PM, Jiri Vanek wrote:
> On 02/24/2015 10:34 AM, Jaroslav Reznik wrote:
>> = Proposed System Wide Change: Legacy implementations of the Java platform in
>> Fedora =
>> 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.
>> === 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-
>> 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
>> 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
> Small restart.
> Looking to the discussion, although many people claimed "against any rules" at the end it seems to
> me that everybody agree on "some rules" - even if it would be existence of metapackage or only
> removed virtual provides and priority....
> From that point of view, do you mind to help me to improve those rules?
Looking to more inputs from https://fedorahosted.org/fpc/ticket/503 :
Current state is fight between -legacy suffix and metapackage with provides.
Except that :
rule 2 is moreover agreed by all.
rule 3 was not discussed by anybody == is ok?
rule 4 was considered only once as to strict, except that seems ok. I don't insists on it. If
nor me nor any of my colleagues will be comaintainer - good. less work for us.
rule 5 and 7 were discussed only shortly without any clear result. However
rule 6 depends whether metapackage or -legacy will win. For metapackage have no real sense.
How I see implementation of this metapackage:
Four java subpackages have virtual provides. *each* of them will to have its own
This subpackage will have all virtual provides of base subpackage and will require the base subpackage.
As legacy jdks must not have the virtual provides, legacy jdks will not have this virtual provides
subpackages of subpackages.
That also means, that the virtual provides subpackages can obsolate the X-1 (virtual provides
sbpackage of subpackage) ones and so the issue with removal of old jdk will be solved.
The fact, that legacy jdk must not even contain this mteasupackages *must* be documented in guidelines.
So at the end the techical result of both -legacy and metapackage is same - Yipii!
However - comparing those two approaches (metapckage/legacy) - the legacy renaming is much simpler.
- no four new packages
- much less and much simpler documentation
- really loud naming if anyone will hit it by accident
- no additional work for people maintinag main jdk
- much less error resistbale at all
metapackges with provides
- four new virtual subapckages
- documentation may be tricky
- legacy x normal main are not recognizeable for person not follwiong the daily happening
- a lot of work for main jdk maintaiers. It is something I really wonted to avoid. As was
mentioned in the thread. Mainting main jdk is quite a lot of work.
In any case, the guidelines are needed.
in f22+ this is complicated also by debug packages (doubleing the number of packages, but this
double is done automatically in loops/via macros)
More information about the devel