From: "Aleksandar Kurtakov" <akurtako(a)redhat.com>
To: "Development discussions related to Fedora"
<devel(a)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(a)redhat.com>
> To: "Development discussions related to Fedora"
> <devel(a)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(a)redhat.com>
> >> To: devel(a)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(a)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...
> >> headless:
> >>
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0...
> >> devel
> >>
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0...
> >> javadoc
> >>
http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0...
> >> 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(a)lists.fedoraproject.org
> >>
https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:
http://fedoraproject.org/code-of-conduct