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

Aleksandar Kurtakov akurtako at redhat.com
Fri Feb 27 11:00:28 UTC 2015


----- Original Message -----
> From: "Aleksandar Kurtakov" <akurtako at redhat.com>
> To: "Development discussions related to Fedora" <devel at lists.fedoraproject.org>
> Sent: Friday, February 27, 2015 12:58:05 PM
> Subject: Re: F22 System Wide Change: Legacy implementations of the Java	platform in Fedora
> 
> ----- Original Message -----
> > From: "Jiri Vanek" <jvanek at redhat.com>
> > To: "Development discussions related to Fedora"
> > <devel at lists.fedoraproject.org>
> > Sent: Friday, February 27, 2015 12:54:04 PM
> > Subject: Re: F22 System Wide Change: Legacy implementations of the Java
> > 	platform in Fedora
> > 
> > On 02/27/2015 11:47 AM, Aleksandar Kurtakov wrote:
> > > ----- Original Message -----
> > >> From: "Jiri Vanek" <jvanek at redhat.com>
> > >> To: devel at lists.fedoraproject.org
> > >> Sent: Friday, February 27, 2015 11:43:53 AM
> > >> Subject: Re: F22 System Wide Change: Legacy implementations of the Java
> > >> 	platform in Fedora
> > >>
> > >> 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 =
> > >>>> 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.
> > >>>>
> > >>>> === 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
> > >>>> _______________________________________________
> > >>>
> > >>>
> > >>> 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?
> > >
> > > If we want to be sure that this legacy jdk will not interfere with the
> > > system JDK let it not provide anything via alternatives. That way people
> > > that want it can use it by playing with PATH/JAVA_HOME (just like they do
> > > with other JVMs).
> > >
> > 
> > I was quite thinking about keeping/removing the alternatives. And at end I
> > came to conclusion that
> > keeping them (if all other rules are kept and so nobody is doing this
> > unvoulenteerly) will bring
> > more benefit then removal.
> > 
> > I actually can imagine that somebody will wont to run his third party app
> > via
> > the legacy jdk.   In
> > this case the alternatives are doing it job pretty well - something like
> > custom satck or whatever.
> 
> The problem with alternatives is they are system wide so if one changes the
> alternatives to point to the legacy JDK for their third party app this
> becomes the JDK system wide. Thus all Fedora packaged Java apps (Tomcat,
> Jetty, JBoss, Freemind, Azureus, Eclipse...) will start using this JDK but
> they will contain jars compiled for newer JDK thus will fail at runtime.

To clarify more on this. That's why in another mail I said using more isolated approach (like scl or PATH/JAVA_HOME) would better be used where one can't make it that easily the system wide JVM.


Alexander Kurtakov
Red Hat Eclipse team

> 
> Alexander Kurtakov
> Red Hat Eclipse team
> 
> > 
> > Ohterwise yes - I'm only 51/49 for keeping alternatives as they are.
> > 
> > 
> > J.
> > >
> > > Alexander Kurtakov
> > > Red Hat Eclipse team
> > >
> > >>
> > >>       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[1] java subpackages have virtual provides. *each* of them will to
> > >> have
> > >> its own
> > >> java-1.X.0-openjdk-subpackageIfany-provides subacklage.
> > >> 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.
> > >> -legacy:
> > >>    - 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.
> > >>
> > >>
> > >>
> > >>
> > >> [1]:
> > >> jre
> > >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec?h=f21#n277
> > >> headless:
> > >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec?h=f21#n310
> > >> devel
> > >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec?h=f21#n347
> > >> javadoc
> > >> http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec?h=f21#n397
> > >> in f22+ this is complicated also by debug packages (doubleing the number
> > >> of
> > >> packages, but this
> > >> double is done automatically in loops/via macros)
> > >> --
> > >> 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
> > 
> > --
> > 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
> --
> 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