----- Original Message ----- > From: "Robert Marcano" <robert@xxxxxxxxxxxxxxxxx> > To: devel@xxxxxxxxxxxxxxxxxxxxxxx > 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@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. > > 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. 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@xxxxxxxxxxxxxxxxxxxxxxx > > https://admin.fedoraproject.org/mailman/listinfo/devel-announce > > > > -- > 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
