----- Original Message ----- > From: "Aleksandar Kurtakov" <akurtako@xxxxxxxxxx> > To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxx> > > To: "Development discussions related to Fedora" > > <devel@xxxxxxxxxxxxxxxxxxxxxxx> > > 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@xxxxxxxxxx> > > >> To: devel@xxxxxxxxxxxxxxxxxxxxxxx > > >> 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@xxxxxxxxxx> > > >>>> > > >>>> 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@xxxxxxxxxxxxxxxxxxxxxxx > > >> https://admin.fedoraproject.org/mailman/listinfo/devel > > >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > > > > -- > > devel mailing list > > devel@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/devel > > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
