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


On 02/26/2015 02:54 PM, Miloslav Trmač wrote:

= Proposed System Wide Change: Legacy implementations of the Java platform in
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora

== Detailed Description ==
This is no real work proposal.


Stepping back, I’m not sure this has been said explicitly: this is really a 
packaging guideline proposal, not really a Change, so it should probably go 
through the FPC.  
(https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Guideline_Change_Procedure
 )

(This is not intended to kill or affect the implementation details discussion 
at all.  I’m just trying to minimize the bureaucracy (hah!) by not setting a 
precedent for doing it this way, so that all future packaging guideline 
proposals go directly to the FPC and skip this redirection step.)
 Mirek


This proposal had been withdraw until real legacy JDK  maintainer is found.

https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora


J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 04:26 PM, Aleksandar Kurtakov wrote:

- Original Message -

From: Robert Marcano rob...@marcanoonline.com
To: devel@lists.fedoraproject.org
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 jva...@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.

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.

This should be out of scope. Nothing of javastack should be
allowed to use use legacy jdk - see rule 7. Togehter with rule 2 it should 
prevent this happening.

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 overorpahned 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

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 jva...@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 overorpahned 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

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

- Original Message -
 From: Jiri Vanek jva...@redhat.com
 To: devel@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 jva...@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 overorpahned 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

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

2015-02-27 Thread Severin Gehwolf

On Thu, 2015-02-26 at 15:46 +0100, Mikolaj Izdebski wrote:
 On 02/26/2015 02:46 PM, Jiri Vanek wrote:
  On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote:
  On 02/26/2015 09:23 AM, Jiri Vanek wrote:
  On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:
  On 02/26/2015 08:42 AM, Jiri Vanek wrote:
  Also, my proposal of introducing java metapackage (see my other
  post
  in this thread), which would always require the latest JDK, solves
  this
  problem in a different way, without modifying ordinary Java packages
  at all.
 
 
  May you be more exact with the metapackage? Before I come up with
  legacy, I hoped to solve the issues via some metapackage. At the end I
  gave up, because the touch of user was always necessary.
 
  I described it in much detail in other posts in this thread
  (for example message-ID 54eca102.1070...@redhat.com)
 
 
  Yah. Sorry. I walked across it later then replied this.
 
  However - I'm not convinced that metapackage will work as expected.  If
  
  Still the metapackge's correct dependence have to be someones
  responsibility. Will you be able to take this burden?
 
 Sure, I can create and maintain metapackage. (In this case it would
 probably be subpackage of javapackages-tools.)
 
  nothing else it will need some changes in current infrastructure which I
  wonted to avoid.
 
  It works exactly how I described it.  Old JDK won't be removed during
  
  Is it really wonted? If so, we can skip the option one and continue
  with with option two.
 
 If you really think that old JDK should be removed during update and
 insist on that then there is still a way to achieve that with versioned
 obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk*  e:v-(r+1),
 where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was
 considered as main JDK. I've just tested it and it works, see below.
 
 
 Lets start with JDK 7 installed.
 
 sh-4.3# rpm -qa | grep java
 java-1.7.0-1.fc23.x86_64
 java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
 
 
 Update installs JDK 8 and erases JDK 7.
 
 sh-4.3# dnf -y update
 Using metadata from Thu Feb 26 15:37:47 2015
 Dependencies resolved.
 Nothing to do.
 sh-4.3# rm -rf /var/cache/dnf/
 sh-4.3# rm -rf rpm
 sh-4.3# dnf -y update
 rpm 966 kB/s | 1.3 kB 00:00
 Using metadata from Thu Feb 26 15:38:06 2015
 Dependencies resolved.
 
  Package  Arch Version  Repository
Size
 
 Installing:
  java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
 Upgrading:
  java x86_64   666:1.8.0-1.fc23 rpm   5.7 k
  replacing  java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23
 
 Transaction Summary
 
 Install  1 Package
 Upgrade  1 Package
 
 Total size: 11 k
 Downloading Packages:
 Running transaction check
 Transaction check succeeded.
 Running transaction test
 Transaction test succeeded.
 Running transaction
   Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
   Upgrading   : java-666:1.8.0-1.fc23.x86_642/4
   Cleanup : java-666:1.7.0-1.fc23.x86_643/4
   Obsoleting  : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4
   Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
   Verifying   : java-666:1.8.0-1.fc23.x86_642/4
   Verifying   : java-666:1.7.0-1.fc23.x86_643/4
   Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4
 
 Installed:
   java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23
 
 Upgraded:
   java.x86_64 666:1.8.0-1.fc23
 
 Complete!
 
 
 After update only JDK 8 is installed:
 
 sh-4.3# rpm -qa | grep java
 java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
 java-1.8.0-1.fc23.x86_64
 
 
 But user can still install JDK 7:
 
 sh-4.3# dnf install -y java-1.7.0-openjdk
 Using metadata from Thu Feb 26 15:38:06 2015
 Dependencies resolved.
 
  Package  Arch Version  Repository
Size
 
 Installing:
  java-1.7.0-openjdk   x86_64   666:1.7.0-2.fc23 rpm   5.7 k
 
 Transaction Summary
 
 Install  1 Package
 
 Total size: 5.7 k
 Installed size: 0
 Downloading Packages:
 Running transaction check
 Transaction check succeeded.
 Running transaction test
 Transaction test succeeded.
 Running transaction
   Installing  : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1
   Verifying   : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1
 
 Installed:
   java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23
 
 Complete!
 
 
 JDK 7 and 8 can coexist without any problem:
 
 sh-4.3# rpm -qa | grep java

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


On 02/27/2015 11:48 AM, Severin Gehwolf wrote:

On Thu, 2015-02-26 at 15:46 +0100, Mikolaj Izdebski wrote:

On 02/26/2015 02:46 PM, Jiri Vanek wrote:

On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote:

On 02/26/2015 09:23 AM, Jiri Vanek wrote:

On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:

On 02/26/2015 08:42 AM, Jiri Vanek wrote:

Also, my proposal of introducing java metapackage (see my other
post
in this thread), which would always require the latest JDK, solves
this
problem in a different way, without modifying ordinary Java packages
at all.



May you be more exact with the metapackage? Before I come up with
legacy, I hoped to solve the issues via some metapackage. At the end I
gave up, because the touch of user was always necessary.


I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)



Yah. Sorry. I walked across it later then replied this.

However - I'm not convinced that metapackage will work as expected.  If


Still the metapackge's correct dependence have to be someones
responsibility. Will you be able to take this burden?


Sure, I can create and maintain metapackage. (In this case it would
probably be subpackage of javapackages-tools.)


nothing else it will need some changes in current infrastructure which I
wonted to avoid.


It works exactly how I described it.  Old JDK won't be removed during


Is it really wonted? If so, we can skip the option one and continue
with with option two.


If you really think that old JDK should be removed during update and
insist on that then there is still a way to achieve that with versioned
obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk*  e:v-(r+1),
where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was
considered as main JDK. I've just tested it and it works, see below.


Lets start with JDK 7 installed.

sh-4.3# rpm -qa | grep java
java-1.7.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64


Update installs JDK 8 and erases JDK 7.

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 15:37:47 2015
Dependencies resolved.
Nothing to do.
sh-4.3# rm -rf /var/cache/dnf/
sh-4.3# rm -rf rpm
sh-4.3# dnf -y update
rpm 966 kB/s | 1.3 kB 00:00
Using metadata from Thu Feb 26 15:38:06 2015
Dependencies resolved.

  Package  Arch Version  Repository
Size

Installing:
  java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
Upgrading:
  java x86_64   666:1.8.0-1.fc23 rpm   5.7 k
  replacing  java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23

Transaction Summary

Install  1 Package
Upgrade  1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
   Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
   Upgrading   : java-666:1.8.0-1.fc23.x86_642/4
   Cleanup : java-666:1.7.0-1.fc23.x86_643/4
   Obsoleting  : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4
   Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
   Verifying   : java-666:1.8.0-1.fc23.x86_642/4
   Verifying   : java-666:1.7.0-1.fc23.x86_643/4
   Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4

Installed:
   java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
   java.x86_64 666:1.8.0-1.fc23

Complete!


After update only JDK 8 is installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
java-1.8.0-1.fc23.x86_64


But user can still install JDK 7:

sh-4.3# dnf install -y java-1.7.0-openjdk
Using metadata from Thu Feb 26 15:38:06 2015
Dependencies resolved.

  Package  Arch Version  Repository
Size

Installing:
  java-1.7.0-openjdk   x86_64   666:1.7.0-2.fc23 rpm   5.7 k

Transaction Summary

Install  1 Package

Total size: 5.7 k
Installed size: 0
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
   Installing  : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1
   Verifying   : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1

Installed:
   java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23

Complete!


JDK 7 and 8 can coexist without any problem:

sh-4.3# rpm -qa | grep java
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-2.fc23.x86_64
java-1.8.0-1.fc23.x86_64

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 jva...@redhat.com
To: devel@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 jva...@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 overorpahned 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

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

- Original Message -
 From: Jiri Vanek jva...@redhat.com
 To: Development discussions related to Fedora 
 devel@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 jva...@redhat.com
  To: devel@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 jva...@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 overorpahned 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

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

- Original Message -
 From: Aleksandar Kurtakov akurt...@redhat.com
 To: Development discussions related to Fedora 
 devel@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 jva...@redhat.com
  To: Development discussions related to Fedora
  devel@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 jva...@redhat.com
   To: devel@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 jva...@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 overorpahned 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

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

On 02/27/2015 11:58 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: Jiri Vanek jva...@redhat.com
To: Development discussions related to Fedora devel@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 jva...@redhat.com
To: devel@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 jva...@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 overorpahned 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

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

On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote:

 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).

That's right.

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/27/2015 10:58 AM, Aleksandar Kurtakov wrote:
 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.

Exactly.  But it's worse than that: someone sets an alternative for
some temporary purpose, then reboots their computer, then they get
pwned via the vulnerable Java.  I'm all for freedom, but we should not
install traps for our users.

Andrew.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 26/02/15 14:59, Mario Torre wrote:

 In this case, it's about giving users one thing they asked, which is
 easy access to a previous version of Java. We can't afford
 maintaining it as Java Team, but this doesn't mean we will refuse to
 help people doing it. In fact, the exact existence of this very same
 discussion is our attempt to pass the ball back to the Community.

It's not just a matter of not being able to afford to continue
maintenance, but the knowledge that unless an obsolete Java
implementation is carefully locked down it may not be safe to use.
This proposal is intended to prevent the accidental use of an obsolete
implementation.  Some of the proposed rules can reasonably be argued
about, but the need to prevent an obsolete Java implementation from
accidentally being used by any part of the Fedora stack isn't.  Of
course, if a user decides to override this that's fine, and we should
not make it unduly difficult, but it shouldn't happen by default in
any Fedora installation.

Andrew.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 25/02/15 00:31, Kevin Kofler wrote:
 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 jva...@redhat.com
 
 IMHO, this is not implementable for a simple practical reason: All the JARs 
 we ship are built from source with our default JDK. They will in general NOT 
 work on any JRE that's older than the default JDK.

That's the idea.  This is not for any part of the Fedora Java stack.

Andrew.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/27/2015 12:04 PM, Andrew Haley wrote:

On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote:


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).


That's right.



In that case, to add another rule -  8) all alternatives bindings must be 
removed - must be added.

J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

Shouldn't this one replace 3). As if there are no alternatives, priorities are 
meaningless.

Alexander Kurtakov
Red Hat Eclipse team

- Original Message -
 From: Jiri Vanek jva...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Friday, February 27, 2015 1:42:53 PM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On 02/27/2015 12:04 PM, Andrew Haley wrote:
  On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote:

  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).

  That's right.

 In that case, to add another rule -  8) all alternatives bindings must be
 removed - must be added.

 J.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/27/2015 12:57 PM, Aleksandar Kurtakov wrote:

Shouldn't this one replace 3). As if there are no alternatives, priorities are 
meaningless.


Sound good.

J.


Alexander Kurtakov
Red Hat Eclipse team


- Original Message -

From: Jiri Vanek jva...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Friday, February 27, 2015 1:42:53 PM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java 
platform in Fedora

On 02/27/2015 12:04 PM, Andrew Haley wrote:

On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote:


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).


That's right.



In that case, to add another rule -  8) all alternatives bindings must be
removed - must be added.

J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/27/2015 12:04 PM, Andrew Haley wrote:

On 02/27/2015 10:47 AM, Aleksandar Kurtakov wrote:


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).


That's right.



One more thing - I'm not sure what everything may break by doing so (dangling symlinks or similar 
issues in the package).


J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 09:43 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: Jiri Vanek jva...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Thursday, February 26, 2015 10:39:35 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java 
platform in Fedora

On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: Mikolaj Izdebski mizde...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Thursday, February 26, 2015 10:16:26 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java
platform in Fedora

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:

Hello,

java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE
changes.
The same is for other binary subpackages of java, respectively.

All system packages would require subpackages of java as they do now
(unless there is good reason not to). Users that install java would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently),

AFAIK nothing obsoletes a package just because it is orphaned…

If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.

How would that work _exactly_?

1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added

We speak about people that are already Fedora packagers, right? Just
sponsoring someone that showed up and let him/her maintain

Still it is possible scenario.

I can even guess that this person will be apckaging newbe - most of java
developers do not care
about packaged stuff below. They have theirs Java EE and are happy that
packages are solving all the
issues they dont like.

On contrary, if such a  person wonts to pack it then you cna expect him to
learn quicly.

   legacy JDK in Fedora is recipe for disaster.

Thats what this guidelines should prevent...

No, no guidelines can prevent someone putting %post rm -fr /etc in a spec file. 
There is a reason for not having blank approval for anybody.

Then we are discussing only one point of this proposal. And I guees formal review one. Level of 
the formalness have to be agreed. And somebody have look over pacakge. I would say the rm rf / in 
postun  is protected by step 5.

By formal review I was higlighting that no jdk package can actually pass 
general review.

J.

Alexander Kurtakov
Red Hat Eclipse team

For not-yet-packagers they would have to go through the full
review-sponsoring process.

Alexander Kurtakov
Red Hat Eclipse team

3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes

--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote:

On 02/26/2015 09:23 AM, Jiri Vanek wrote:

On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:

On 02/26/2015 08:42 AM, Jiri Vanek wrote:

Also, my proposal of introducing java metapackage (see my other post
in this thread), which would always require the latest JDK, solves
this
problem in a different way, without modifying ordinary Java packages
at all.

May you be more exact with the metapackage? Before I come up with
legacy, I hoped to solve the issues via some metapackage. At the end I
gave up, because the touch of user was always necessary.

I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)

Yah. Sorry. I walked across it later then replied this.

However - I'm not convinced that metapackage will work as expected. If

Still the metapackge's correct dependence have to be someones responsibility. Will you be able to
take this burden?

nothing else it will need some changes in current infrastructure which I
wonted to avoid.

It works exactly how I described it. Old JDK won't be removed during

Is it really wonted? If so, we can skip the option one and continue with with
option two.

update, but that's expected behaviour of package management software,
such as DNF, and JDK packages should not differ from other Fedora

Really should not? We done pretty god work to have only one main jdk unlike python1, python2,python3
or glib2,glib3,glibN... We are settled in special directory and so on. So in what is JDK actually
similar to other packages?

packages in this aspect. Consider a detailed example below.

Thank you for this. I understood it from yuor describtion and already had the same. However I
consider the keeping of old jdk as no-go for this.

Assume we start with Java 7:

sh-4.3# rpm -qa | grep java
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.7.0-1.fc23.x86_64

Then update to newer version of java metapackage, which brings Java 8:

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

Package Arch Version Repository
Size

Installing:
java-1.8.0-openjdk x86_64 666:1.8.0-1.fc23 rpm 5.6 k
Upgrading:
java x86_64 666:1.8.0-1.fc23 rpm 5.6 k

Transaction Summary

Install 1 Package
Upgrade 1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Installing : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/3
Upgrading : java-666:1.8.0-1.fc23.x86_642/3
Cleanup : java-666:1.7.0-1.fc23.x86_643/3
Verifying : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6 1/3
Verifying : java-666:1.8.0-1.fc23.x86_642/3
Verifying : java-666:1.7.0-1.fc23.x86_643/3

Installed:
java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
java.x86_64 666:1.8.0-1.fc23

Complete!

Now both Java 8 and legacy Java 7 are installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64

But user can easily remove packages which were installed to satisfy
dependency, but which are no longer needed using autoremove command:

sh-4.3# dnf -y autoremove
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

Package ArchVersion Repository
Size

Removing:
java-1.7.0-openjdk x86_64 666:1.7.0-1.fc23@System0

Transaction Summary

Remove 1 Package

Installed size: 0
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Erasing : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 1/1
Verifying : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6 1/1

Removed:
java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23

After autoremove Java 7 is no longer installed:

Complete!
sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-26 Thread Mario Torre

On Thu, 2015-02-26 at 09:00 +0100, Jiri Vanek wrote:
 On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote:
  Hi All,
 
  I have been reading this mail chain for some time and there is something I 
  wanted to say. It's kind
  of a long mail, I apologize for taking so much of your time but request you 
  to please bear with me.
  I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and 
  Python technology stacks,
  who has to code on Java/J2EEquite often as well and I use Fedora 21 
  Workstation as my primary OS. My
  field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, 
  all from time to time.
  This is because as time passed, solutions delivered to customers were built 
  using incremental
  versions of Java/J2EE specifications and were not frequently upgraded. In 
  my role, the changes/fixes
  I do to these enterprise apps are usually small and require only a certain 
  jar file to be
  recompiled, or in some cases only one class. In such cases, maintaining 
  binary compatibility is a
  must and for that I need to recompile that one jar/class with the original 
  version of JDK that was
  used to compile the rest of the project in the first place.
 
  I use Oracle java in most cases due to corporate policies (for personal 
  use, I use the latest
  version of OpenJDK). Now as per Oracle's policy, which I am sure is similar 
  for OpenJDK as well, a
  particular version of JDK/JRE is updated till and even some time after the 
  next major version is
  released, and then at a certain Update level, Oracle stops supporting it. 
  That update version
  becomes the final update for that particular major release, and is sent 
  into archives, while updates
  keep on getting released for the current version.
 
  With Oracle JDK, there are two installation approaches available for RPM 
  based systems. They provide
  an RPM package which installs java in /usr/java, i.e. in system area and 
  the latest installed java
  version become default. However, they also provides tarballs of JDKs, that 
  contain certain standard
  directory structure of JDK  intact inside one folder. These tarballs can be 
  extracted and placed in
  any place on file system and once JAVA_HOME is pointed towards these+PATH 
  is locally updated to
  include it, user can basically use this JDK without any issues. What 
  version of Java is installed in
  system as default, in system area (/usr/java) become irrelevant.
 
  With IDEs like Eclipse and NetBeans the process is even simpler, as you can 
  define these individual
  folders as JDKs for particular API versions in IDE configuration 
  permanently and while creating a
  project can choose to use any of these defined JDKs. This is the approach 
  that I take. I have the
  last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I 
  have these configured in
  Eclipse and NetBeans for each API version and I use them all as required by 
  the project.
 
  So I guess if OpenJDK can follow the same approach and can give an option 
  to download tarballs of
  older versions and use them in place, without requiring any installation, 
  as a definite directory
  structure, then the problem is solved. There is no need to maintain old 
  version per se in
  repositories, as these are not updated anymore and the user will be able to 
  use multiple versions
  without conflict of any kind. As for the default JDK, it can be kept how it 
  is now i.e. The latest
  available JDK can be maintained in Fedora repos as they are being 
  maintained now and updates can be
  provided for the defined lifetime of that JDK.
 
  Let me know what you guys think about this approach.
 
 
 This is lying on  openjdk table for long time to have  at least source 
 tarballs... As you can see, 
 nothing,.  However  once you are able to build jdk on your own,  nothing 
 prevents you form mercurial 
 clone of *any* version. So this is the way you should go.
 
 If you wont binary images to be supported by openjdk itself, its completely 
 different and more 
 complex story.

Indeed, and for that you need to go to an OS that supports long term
stability, like RHEL or Centos (playing in house, but you have other
choices). Fedora is not really good for that, since it promotes bleeding
edge code over long term stability.

Cheers,
Mario


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-26 Thread Mario Torre

On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote:
 On 02/24/2015 05:21 PM, Mario Torre wrote:
  On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
  On 02/24/2015 02:15 PM, Jiri Vanek wrote:
  On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
  I am against official guidelines or policy for legacy JDK packages. I
  don't think that any such policy is needed and it would only encourage
  adoption of old packages for which there might be no security updates.
 
  Well thats the point - people are calling for them. And wont to maintain
  them with this risk.
 
  I thought that the point of this change proposal was enabling community
  to maintain legacy JDKs, not encouraging people to package them without
  good reason or without involvement to truly maintaining them. Packaging
  older JDKs is *already* possible, so IMHO this change accomplishes
  nothing but showing people how they can dump old, unmaintained software
  into Fedora.
  
  Well, in this case it would not be un-maintained, the Fedora package
  would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
  are still actively contributing to the upstream software in its various
  versions. While you as a packager cannot specifically count on that,
  there's still a level of confidence that the base software won't be
  abandoned any time soon. And even when we will stop supporting those
  older versions, the community will take over if there is a need for
  that, exactly like we have done ourselves before.
  
  Indeed, there's an overhead for the downstream maintainers, we may need
  to drop specific version of OpenJDK, or skip a release, or do other
  funny things and the Fedora maintainers will have to adapt, but this is
  no different than usual I believe. Realistically, we are so conservative
  with older JDKs that I doubt this will ever really be an issue.
 
 Correct me if I am wrong, but in my understanding maintaining JDK
 package requires a lot of ongoing work (including obtaining and applying
 patches, running TCK, pushing updates in timely manner and so on). JDK
 maintainers should know this and I'm assuming that the amount of
 required work is the main reason for them not wanting to maintain older
 JDKs.
 
 The work required to add old JDK package to Fedora is relatively small
 compared to ongoing maintenance work. Someone willing to truly maintain
 JDK in Fedora should have knowledge about JDK packaging and they
 shouldn't have problem finding time to come up with a working solution,
 proposing and discussing it.

Indeed, but don't underestimate this relatively, which is the main
reason why *we* won't do that.

 If you make the process of adding legacy JDKs to Fedora too easy then
 someone without enough time and required knowledge will surely do that
 and we may easily end with unmaintained package. I'd rather not have old
 JDK than have unmaintained JDK with security holes.

I don't see how giving proper rules means making something like that
easy. The fact is that making things artificially complicated just to
scare off people from doing them doesn't really match with my view of
Freedom. I think instead that rules, however complex for the matter at
hand, should be crafted so that they impose the minimum possible
overhead.

In this case, it's about giving users one thing they asked, which is
easy access to a previous version of Java. We can't afford maintaining
it as Java Team, but this doesn't mean we will refuse to help people
doing it. In fact, the exact existence of this very same discussion is
our attempt to pass the ball back to the Community.

  Package that doesn't pass review shouldn't be part of Fedora.
  
  Well, if your goal is to reduce the user base of Fedora, I'm sure we can
  talk about removing the JDK :)
 
 We can't sacrifice our basic principles (such as passing review) for the
 sake of increasing user base.

If you put the mean before the end, yes. But I hope you will agree with
me that one of those core principles *is* the Freedom of allowing users
to use such a critical tool as Java for their own daily reasons
*without* forcing them to switch distribution.

While I see your point that this can be extended to anything (why don't
we package an older Eclipse?) so we need to draw a line, I believe an
important core component like the JDK falls in that category of things
that should be allowed to coexist even a bit longer than originally
intended.

Now, the question is how to make this happens by preserving both quality
and freedom.

Cheers,
Mario


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 02:51 PM, Jiri Vanek wrote:
 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?

As always I'm happy to help improving state of Java in Fedora. Next week
I'm on vacation [1], but after I come back I can work on this. Once we
agree on requirements and other assumptions then finding optimal
solution should be easy.

[1] https://apps.fedoraproject.org/calendar/vacation/#m2268

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

- Original Message -
 From: Mario Torre neug...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, February 26, 2015 4:59:35 PM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote:
  On 02/24/2015 05:21 PM, Mario Torre wrote:
   On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
   On 02/24/2015 02:15 PM, Jiri Vanek wrote:
   On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
   I am against official guidelines or policy for legacy JDK packages. I
   don't think that any such policy is needed and it would only encourage
   adoption of old packages for which there might be no security updates.

   Well thats the point - people are calling for them. And wont to
   maintain
   them with this risk.

   I thought that the point of this change proposal was enabling community
   to maintain legacy JDKs, not encouraging people to package them without
   good reason or without involvement to truly maintaining them. Packaging
   older JDKs is *already* possible, so IMHO this change accomplishes
   nothing but showing people how they can dump old, unmaintained software
   into Fedora.

   Well, in this case it would not be un-maintained, the Fedora package
   would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
   are still actively contributing to the upstream software in its various
   versions. While you as a packager cannot specifically count on that,
   there's still a level of confidence that the base software won't be
   abandoned any time soon. And even when we will stop supporting those
   older versions, the community will take over if there is a need for
   that, exactly like we have done ourselves before.

   Indeed, there's an overhead for the downstream maintainers, we may need
   to drop specific version of OpenJDK, or skip a release, or do other
   funny things and the Fedora maintainers will have to adapt, but this is
   no different than usual I believe. Realistically, we are so conservative
   with older JDKs that I doubt this will ever really be an issue.

  Correct me if I am wrong, but in my understanding maintaining JDK
  package requires a lot of ongoing work (including obtaining and applying
  patches, running TCK, pushing updates in timely manner and so on). JDK
  maintainers should know this and I'm assuming that the amount of
  required work is the main reason for them not wanting to maintain older
  JDKs.

  The work required to add old JDK package to Fedora is relatively small
  compared to ongoing maintenance work. Someone willing to truly maintain
  JDK in Fedora should have knowledge about JDK packaging and they
  shouldn't have problem finding time to come up with a working solution,
  proposing and discussing it.

 Indeed, but don't underestimate this relatively, which is the main
 reason why *we* won't do that.

  If you make the process of adding legacy JDKs to Fedora too easy then
  someone without enough time and required knowledge will surely do that
  and we may easily end with unmaintained package. I'd rather not have old
  JDK than have unmaintained JDK with security holes.

 I don't see how giving proper rules means making something like that
 easy. The fact is that making things artificially complicated just to
 scare off people from doing them doesn't really match with my view of
 Freedom. I think instead that rules, however complex for the matter at
 hand, should be crafted so that they impose the minimum possible
 overhead.

 In this case, it's about giving users one thing they asked, which is
 easy access to a previous version of Java. We can't afford maintaining
 it as Java Team, but this doesn't mean we will refuse to help people
 doing it. In fact, the exact existence of this very same discussion is
 our attempt to pass the ball back to the Community.

   Package that doesn't pass review shouldn't be part of Fedora.

   Well, if your goal is to reduce the user base of Fedora, I'm sure we can
   talk about removing the JDK :)

  We can't sacrifice our basic principles (such as passing review) for the
  sake of increasing user base.

 If you put the mean before the end, yes. But I hope you will agree with
 me that one of those core principles *is* the Freedom of allowing users
 to use such a critical tool as Java for their own daily reasons
 *without* forcing them to switch distribution.

 While I see your point that this can be extended to anything (why don't
 we package an older Eclipse?) so we need to draw a line, I believe an
 important core component like the JDK falls in that category of things
 that should be allowed to coexist even a bit longer than originally
 intended.

 Now, the question is how to make this happens by preserving both quality
 and freedom.

Adding exceptions for selected packages is definitively not the way to go.
I

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

- Original Message -
 From: Robert Marcano rob...@marcanoonline.com
 To: devel@lists.fedoraproject.org
 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 jva...@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.

 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 overorpahned 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

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

On 02/26/2015 02:46 PM, Jiri Vanek wrote:
 On 02/26/2015 10:13 AM, Mikolaj Izdebski wrote:
 On 02/26/2015 09:23 AM, Jiri Vanek wrote:
 On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:
 On 02/26/2015 08:42 AM, Jiri Vanek wrote:
 Also, my proposal of introducing java metapackage (see my other
 post
 in this thread), which would always require the latest JDK, solves
 this
 problem in a different way, without modifying ordinary Java packages
 at all.


 May you be more exact with the metapackage? Before I come up with
 legacy, I hoped to solve the issues via some metapackage. At the end I
 gave up, because the touch of user was always necessary.

 I described it in much detail in other posts in this thread
 (for example message-ID 54eca102.1070...@redhat.com)


 Yah. Sorry. I walked across it later then replied this.

 However - I'm not convinced that metapackage will work as expected.  If
 
 Still the metapackge's correct dependence have to be someones
 responsibility. Will you be able to take this burden?

Sure, I can create and maintain metapackage. (In this case it would
probably be subpackage of javapackages-tools.)

 nothing else it will need some changes in current infrastructure which I
 wonted to avoid.

 It works exactly how I described it.  Old JDK won't be removed during
 
 Is it really wonted? If so, we can skip the option one and continue
 with with option two.

If you really think that old JDK should be removed during update and
insist on that then there is still a way to achieve that with versioned
obsoletes. Metapackage would Obsolete: java-1.N.0-openjdk*  e:v-(r+1),
where e:v-r is the latest evr of java-1.N.0-openjdk* when JDK N was
considered as main JDK. I've just tested it and it works, see below.


Lets start with JDK 7 installed.

sh-4.3# rpm -qa | grep java
java-1.7.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64


Update installs JDK 8 and erases JDK 7.

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 15:37:47 2015
Dependencies resolved.
Nothing to do.
sh-4.3# rm -rf /var/cache/dnf/
sh-4.3# rm -rf rpm
sh-4.3# dnf -y update
rpm 966 kB/s | 1.3 kB 00:00
Using metadata from Thu Feb 26 15:38:06 2015
Dependencies resolved.

 Package  Arch Version  Repository
   Size

Installing:
 java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
Upgrading:
 java x86_64   666:1.8.0-1.fc23 rpm   5.7 k
 replacing  java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23

Transaction Summary

Install  1 Package
Upgrade  1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
  Upgrading   : java-666:1.8.0-1.fc23.x86_642/4
  Cleanup : java-666:1.7.0-1.fc23.x86_643/4
  Obsoleting  : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4
  Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/4
  Verifying   : java-666:1.8.0-1.fc23.x86_642/4
  Verifying   : java-666:1.7.0-1.fc23.x86_643/4
  Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   4/4

Installed:
  java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
  java.x86_64 666:1.8.0-1.fc23

Complete!


After update only JDK 8 is installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
java-1.8.0-1.fc23.x86_64


But user can still install JDK 7:

sh-4.3# dnf install -y java-1.7.0-openjdk
Using metadata from Thu Feb 26 15:38:06 2015
Dependencies resolved.

 Package  Arch Version  Repository
   Size

Installing:
 java-1.7.0-openjdk   x86_64   666:1.7.0-2.fc23 rpm   5.7 k

Transaction Summary

Install  1 Package

Total size: 5.7 k
Installed size: 0
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1
  Verifying   : java-1.7.0-openjdk-666:1.7.0-2.fc23.x86_6   1/1

Installed:
  java-1.7.0-openjdk.x86_64 666:1.7.0-2.fc23

Complete!


JDK 7 and 8 can coexist without any problem:

sh-4.3# rpm -qa | grep java
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-2.fc23.x86_64
java-1.8.0-1.fc23.x86_64


-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org

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

2015-02-26 Thread Robert Marcano


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 jva...@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.


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.




=== 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 overorpahned 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-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct:

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


On 02/26/2015 04:20 PM, Robert Marcano wrote:

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 jva...@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.


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.



The legacy jdk have not unvoulenteerly run this regular fedora-java stack code - never. Thats what 
those rules should achieve.


The usage should be for third party development/usage only.


J.




=== 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 overorpahned 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

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


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 jva...@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 overorpahned 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?


J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-26 Thread Miloslav Trmač

 = Proposed System Wide Change: Legacy implementations of the Java platform in
 Fedora =
 https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora
 
 == Detailed Description ==
 This is no real work proposal.

Stepping back, I’m not sure this has been said explicitly: this is really a 
packaging guideline proposal, not really a Change, so it should probably go 
through the FPC.  
(https://fedoraproject.org/wiki/Packaging_Committee?rd=Packaging:Committee#Guideline_Change_Procedure
 )

(This is not intended to kill or affect the implementation details discussion 
at all.  I’m just trying to minimize the bureaucracy (hah!) by not setting a 
precedent for doing it this way, so that all future packaging guideline 
proposals go directly to the FPC and skip this redirection step.)
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-26 Thread Przemek Klosowski


On 02/26/2015 09:46 AM, Mikolaj Izdebski wrote:
If you really think that old JDK should be removed during update and 
insist on that
I believe that at least on Windows apps, including browser apps, can 
request a specific version of Java runtime. Malware asks for versions 
that are vulnerable to whatever they're up to, of course. Therefore, 
yes, old runtime has to be deleted unless the user specifically requests 
it, presumably because some obsolete app depends on it ('write once, 
debug everywhere').
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 08:36 PM, Sumit Bhardwaj wrote:

Hi All,

I have been reading this mail chain for some time and there is something I
wanted to say. It's kind
of a long mail, I apologize for taking so much of your time but request you to
please bear with me.
I work as a technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and
Python technology stacks,
who has to code on Java/J2EEquite often as well and I use Fedora 21 Workstation
as my primary OS. My
field of work is such that I need to use JDK versions 1.4, 5, 6, 7 and 8, all
from time to time.
This is because as time passed, solutions delivered to customers were built
using incremental
versions of Java/J2EE specifications and were not frequently upgraded. In my
role, the changes/fixes
I do to these enterprise apps are usually small and require only a certain jar
file to be
recompiled, or in some cases only one class. In such cases, maintaining binary
compatibility is a
must and for that I need to recompile that one jar/class with the original
version of JDK that was
used to compile the rest of the project in the first place.

I use Oracle java in most cases due to corporate policies (for personal use, I
use the latest
version of OpenJDK). Now as per Oracle's policy, which I am sure is similar for
OpenJDK as well, a
particular version of JDK/JRE is updated till and even some time after the next
major version is
released, and then at a certain Update level, Oracle stops supporting it. That
update version
becomes the final update for that particular major release, and is sent into
archives, while updates
keep on getting released for the current version.

With Oracle JDK, there are two installation approaches available for RPM based
systems. They provide
an RPM package which installs java in /usr/java, i.e. in system area and the
latest installed java
version become default. However, they also provides tarballs of JDKs, that
contain certain standard
directory structure of JDK intact inside one folder. These tarballs can be
extracted and placed in
any place on file system and once JAVA_HOME is pointed towards these+PATH is
locally updated to
include it, user can basically use this JDK without any issues. What version of
Java is installed in
system as default, in system area (/usr/java) become irrelevant.

With IDEs like Eclipse and NetBeans the process is even simpler, as you can
define these individual
folders as JDKs for particular API versions in IDE configuration permanently
and while creating a
project can choose to use any of these defined JDKs. This is the approach
that I take. I have the
last updated versions of all the JDKs from 1.4 to 8 in my /opt folder. I have
these configured in
Eclipse and NetBeans for each API version and I use them all as required by the
project.

So I guess if OpenJDK can follow the same approach and can give an option to
download tarballs of
older versions and use them in place, without requiring any installation, as a
definite directory
structure, then the problem is solved. There is no need to maintain old version
per se in
repositories, as these are not updated anymore and the user will be able to use
multiple versions
without conflict of any kind. As for the default JDK, it can be kept how it is
now i.e. The latest
available JDK can be maintained in Fedora repos as they are being maintained
now and updates can be
provided for the defined lifetime of that JDK.

Let me know what you guys think about this approach.

This is lying on openjdk table for long time to have at least source tarballs... As you can see,
nothing,. However once you are able to build jdk on your own, nothing prevents you form mercurial
clone of *any* version. So this is the way you should go.

If you wont binary images to be supported by openjdk itself, its completely different and more
complex story.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 06:22 PM, Mikolaj Izdebski wrote:

On 02/24/2015 05:21 PM, Mario Torre wrote:

On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:

On 02/24/2015 02:15 PM, Jiri Vanek wrote:

On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:

I am against official guidelines or policy for legacy JDK packages. I
don't think that any such policy is needed and it would only encourage
adoption of old packages for which there might be no security updates.


Well thats the point - people are calling for them. And wont to maintain
them with this risk.


I thought that the point of this change proposal was enabling community
to maintain legacy JDKs, not encouraging people to package them without
good reason or without involvement to truly maintaining them. Packaging
older JDKs is *already* possible, so IMHO this change accomplishes
nothing but showing people how they can dump old, unmaintained software
into Fedora.


Well, in this case it would not be un-maintained, the Fedora package
would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
are still actively contributing to the upstream software in its various
versions. While you as a packager cannot specifically count on that,
there's still a level of confidence that the base software won't be
abandoned any time soon. And even when we will stop supporting those
older versions, the community will take over if there is a need for
that, exactly like we have done ourselves before.

Indeed, there's an overhead for the downstream maintainers, we may need
to drop specific version of OpenJDK, or skip a release, or do other
funny things and the Fedora maintainers will have to adapt, but this is
no different than usual I believe. Realistically, we are so conservative
with older JDKs that I doubt this will ever really be an issue.


Correct me if I am wrong, but in my understanding maintaining JDK
package requires a lot of ongoing work (including obtaining and applying


Here you are right,


patches, running TCK, pushing updates in timely manner and so on). JDK
maintainers should know this and I'm assuming that the amount of
required work is the main reason for them not wanting to maintain older
JDKs.



I would say here you are not. No one will force the legacy jdks to be uodated. And afaik there will 
be no need to do it somehow furiously.


Keeping package of EOLed programis actually most simple thing... (unles it FBfS and die by naturalk 
death)




The work required to add old JDK package to Fedora is relatively small
compared to ongoing maintenance work. Someone willing to truly maintain
JDK in Fedora should have knowledge about JDK packaging and they
shouldn't have problem finding time to come up with a working solution,
proposing and discussing it.

If you make the process of adding legacy JDKs to Fedora too easy then
someone without enough time and required knowledge will surely do that


Thats not an intention of the proposal.
But the need to highlight that regular review can not appy to java packages was 
necessary.


and we may easily end with unmaintained package. I'd rather not have old
JDK than have unmaintained JDK with security holes.


There is no workaround for human factor.



Package that doesn't pass review shouldn't be part of Fedora.


Well, if your goal is to reduce the user base of Fedora, I'm sure we can
talk about removing the JDK :)


We can't sacrifice our basic principles (such as passing review) for the
sake of increasing user base.



As told, it is not it. But java packages will not never ever pass regular review. And in adition the 
legacy ones will probably need to follow even more rules (aka this proposal...)


J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/26/2015 09:16 AM, Mikolaj Izdebski wrote:

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:

Hello,

java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of java, respectively.

All system packages would require subpackages of java as they do now
(unless there is good reason not to). Users that install java would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently),


AFAIK nothing obsoletes a package just because it is orphaned…


If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.


How would that work _exactly_?


1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added


This is heavily untrue. The obsolete (or similar mechanism) is necessary.
We do not wont any user to live unvoulenteerly and unwillingly  with legacy jdk. I would like also 
to avoid just keeping the legacy jdk on his drive.

Two reasons
1- the stack will eb compiled by nex (newr) jdk - so old jdk will not be bel 
tun it.
  - even keeping it on drive may lead to risk of usage it (speaking about basic user here). Not 
speaking about vasting of space on drive after several major updates.


2- low mainatainance. The community maintained jdk can never be expected to be so uptodate == so 
safe asmain jdk, which is mainatined by openjdk upstream-working people.


3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 09:23 AM, Jiri Vanek wrote:
 On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:
 On 02/26/2015 08:42 AM, Jiri Vanek wrote:
 Also, my proposal of introducing java metapackage (see my other post
 in this thread), which would always require the latest JDK, solves
 this
 problem in a different way, without modifying ordinary Java packages
 at all.


 May you be more exact with the metapackage? Before I come up with
 legacy, I hoped to solve the issues via some metapackage. At the end I
 gave up, because the touch of user was always necessary.

 I described it in much detail in other posts in this thread
 (for example message-ID 54eca102.1070...@redhat.com)

 
 Yah. Sorry. I walked across it later then replied this.
 
 However - I'm not convinced that metapackage will work as expected.  If
 nothing else it will need some changes in current infrastructure which I
 wonted to avoid.

It works exactly how I described it.  Old JDK won't be removed during
update, but that's expected behaviour of package management software,
such as DNF, and JDK packages should not differ from other Fedora
packages in this aspect. Consider a detailed example below.


Assume we start with Java 7:

sh-4.3# rpm -qa | grep java
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.7.0-1.fc23.x86_64


Then update to newer version of java metapackage, which brings Java 8:

sh-4.3# dnf -y update
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

 Package  Arch Version  Repository
   Size

Installing:
 java-1.8.0-openjdk   x86_64   666:1.8.0-1.fc23 rpm   5.6 k
Upgrading:
 java x86_64   666:1.8.0-1.fc23 rpm   5.6 k

Transaction Summary

Install  1 Package
Upgrade  1 Package

Total size: 11 k
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Installing  : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/3
  Upgrading   : java-666:1.8.0-1.fc23.x86_642/3
  Cleanup : java-666:1.7.0-1.fc23.x86_643/3
  Verifying   : java-1.8.0-openjdk-666:1.8.0-1.fc23.x86_6   1/3
  Verifying   : java-666:1.8.0-1.fc23.x86_642/3
  Verifying   : java-666:1.7.0-1.fc23.x86_643/3

Installed:
  java-1.8.0-openjdk.x86_64 666:1.8.0-1.fc23

Upgraded:
  java.x86_64 666:1.8.0-1.fc23

Complete!


Now both Java 8 and legacy Java 7 are installed:

sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.7.0-openjdk-1.7.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64


But user can easily remove packages which were installed to satisfy
dependency, but which are no longer needed using autoremove command:

sh-4.3# dnf -y autoremove
Using metadata from Thu Feb 26 09:51:07 2015
Dependencies resolved.

 Package ArchVersion Repository
   Size

Removing:
 java-1.7.0-openjdk  x86_64  666:1.7.0-1.fc23@System0

Transaction Summary

Remove  1 Package

Installed size: 0
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Erasing : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   1/1
  Verifying   : java-1.7.0-openjdk-666:1.7.0-1.fc23.x86_6   1/1

Removed:
  java-1.7.0-openjdk.x86_64 666:1.7.0-1.fc23


After autoremove Java 7 is no longer installed:

Complete!
sh-4.3# rpm -qa | grep java
java-1.8.0-1.fc23.x86_64
java-1.8.0-openjdk-1.8.0-1.fc23.x86_64



-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:
 On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
 Hello,
 java would be the preferred JRE in Fedora. The package would have no
 content, but it would have Requires on preferred Fedora JRE, currently
 java-1.8.0-openjdk. This could be easily changed as default JRE changes.
 The same is for other binary subpackages of java, respectively.

 All system packages would require subpackages of java as they do now
 (unless there is good reason not to). Users that install java would
 get latest JRE, which would be updated to new major versions as they
 become default. Older JDKs would not be removed during update (unless
 there is no maintainer and they are obsoleted as currently),

 AFAIK nothing obsoletes a package just because it is orphaned…

 If no volunteer shows up for maintenance of old JDK then it would be
 deprecated and obsoleted, as it's was done with previous JDK packages.
 
 How would that work _exactly_?

1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added

3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 08:45 AM, Jiri Vanek wrote:
 I'm not really proposing as I haven't thought about this much yet, but
 the idea was about be adding a few empty binary packages java,
 java-devel, java-headless and so on (they could be subpackages of
 javapackages-tools). Existing provides with the same names could be
 removed from JDK packages.

 java would be the preferred JRE in Fedora. The package would have no
 content, but it would have Requires on preferred Fedora JRE, currently
 java-1.8.0-openjdk. This could be easily changed as default JRE changes.
 The same is for other binary subpackages of java, respectively.

 All system packages would require subpackages of java as they do now
 (unless there is good reason not to). Users that install java would
 get latest JRE, which would be updated to new major versions as they
 become default. Older JDKs would not be removed during update (unless
 there is no maintainer and they are obsoleted as currently), but users
 could remove them with yum autoremove, unless something requires older
 JDK or they installed it explicitly.
 
 Does it really seem to you as more simple  solution both for packagers
 and users?
 
 it does snot to me...

Yes, IMO it is much simpler than the policy you are proposing.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

- Original Message -
 From: Mikolaj Izdebski mizde...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Thursday, February 26, 2015 10:16:26 AM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On 02/25/2015 06:58 PM, Miloslav Trmač wrote:
  On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
  Hello,
  java would be the preferred JRE in Fedora. The package would have no
  content, but it would have Requires on preferred Fedora JRE, currently
  java-1.8.0-openjdk. This could be easily changed as default JRE changes.
  The same is for other binary subpackages of java, respectively.

  All system packages would require subpackages of java as they do now
  (unless there is good reason not to). Users that install java would
  get latest JRE, which would be updated to new major versions as they
  become default. Older JDKs would not be removed during update (unless
  there is no maintainer and they are obsoleted as currently),

  AFAIK nothing obsoletes a package just because it is orphaned…

  If no volunteer shows up for maintenance of old JDK then it would be
  deprecated and obsoleted, as it's was done with previous JDK packages.

  How would that work _exactly_?

 1) JDK maintainers announce deprecation in advance and call for
 volunteers to maintain old JDK

 2) when the time of deprecation comes, JDK package is reassigned to new
 maintainer, if such showed up; no obsoletes are added

We speak about people that are already Fedora packagers, right? Just sponsoring 
someone that showed up and let him/her maintain legacy JDK in Fedora is recipe 
for disaster.
For not-yet-packagers they would have to go through the full review-sponsoring 
process.

Alexander Kurtakov
Red Hat Eclipse team

 3) if there is no new maintainer then old JDK is redired in pkgdb,
 blocked in koji and obsoleted by some other package

 4) if maintainer shows up after old JDK was retired then he can just
 revive package (passing review if needed); package release is bumped to
 be higher that obsoletes

 --
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:

- Original Message -

From: Mikolaj Izdebski mizde...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Thursday, February 26, 2015 10:16:26 AM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java 
platform in Fedora

On 02/25/2015 06:58 PM, Miloslav Trmač wrote:

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:

Hello,

java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of java, respectively.

All system packages would require subpackages of java as they do now
(unless there is good reason not to). Users that install java would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently),

AFAIK nothing obsoletes a package just because it is orphaned…

If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.

How would that work _exactly_?

1) JDK maintainers announce deprecation in advance and call for
volunteers to maintain old JDK

2) when the time of deprecation comes, JDK package is reassigned to new
maintainer, if such showed up; no obsoletes are added

We speak about people that are already Fedora packagers, right? Just sponsoring 
someone that showed up and let him/her maintain

Still it is possible scenario.

I can even guess that this person will be apckaging newbe - most of java developers do not care 
about packaged stuff below. They have theirs Java EE and are happy that packages are solving all the 
issues they dont like.

On contrary, if such a  person wonts to pack it then you cna expect him to 
learn quicly.

 legacy JDK in Fedora is recipe for disaster.

Thats what this guidelines should prevent...

For not-yet-packagers they would have to go through the full review-sponsoring 
process.

Alexander Kurtakov
Red Hat Eclipse team

3) if there is no new maintainer then old JDK is redired in pkgdb,
blocked in koji and obsoleted by some other package

4) if maintainer shows up after old JDK was retired then he can just
revive package (passing review if needed); package release is bumped to
be higher that obsoletes

--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

- Original Message -
 From: Jiri Vanek jva...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Thursday, February 26, 2015 10:39:35 AM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:
  - Original Message -
  From: Mikolaj Izdebski mizde...@redhat.com
  To: devel@lists.fedoraproject.org
  Sent: Thursday, February 26, 2015 10:16:26 AM
  Subject: Re: F22 System Wide Change: Legacy implementations of the Java
 platform in Fedora

  On 02/25/2015 06:58 PM, Miloslav Trmač wrote:
  On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
  Hello,
  java would be the preferred JRE in Fedora. The package would have no
  content, but it would have Requires on preferred Fedora JRE, currently
  java-1.8.0-openjdk. This could be easily changed as default JRE
  changes.
  The same is for other binary subpackages of java, respectively.

  All system packages would require subpackages of java as they do now
  (unless there is good reason not to). Users that install java would
  get latest JRE, which would be updated to new major versions as they
  become default. Older JDKs would not be removed during update (unless
  there is no maintainer and they are obsoleted as currently),

  AFAIK nothing obsoletes a package just because it is orphaned…

  If no volunteer shows up for maintenance of old JDK then it would be
  deprecated and obsoleted, as it's was done with previous JDK packages.

  How would that work _exactly_?

  1) JDK maintainers announce deprecation in advance and call for
  volunteers to maintain old JDK

  2) when the time of deprecation comes, JDK package is reassigned to new
  maintainer, if such showed up; no obsoletes are added

  We speak about people that are already Fedora packagers, right? Just
  sponsoring someone that showed up and let him/her maintain
 Still it is possible scenario.

 I can even guess that this person will be apckaging newbe - most of java
 developers do not care
 about packaged stuff below. They have theirs Java EE and are happy that
 packages are solving all the
 issues they dont like.

 On contrary, if such a  person wonts to pack it then you cna expect him to
 learn quicly.

   legacy JDK in Fedora is recipe for disaster.

 Thats what this guidelines should prevent...

No, no guidelines can prevent someone putting %post rm -fr /etc in a spec file. 
There is a reason for not having blank approval for anybody.

Alexander Kurtakov
Red Hat Eclipse team

  For not-yet-packagers they would have to go through the full
  review-sponsoring process.

  Alexander Kurtakov
  Red Hat Eclipse team

  3) if there is no new maintainer then old JDK is redired in pkgdb,
  blocked in koji and obsoleted by some other package

  4) if maintainer shows up after old JDK was retired then he can just
  revive package (passing review if needed); package release is bumped to
  be higher that obsoletes

  --
  Mikolaj Izdebski
  Software Engineer, Red Hat
  IRC: mizdebsk
  --
  devel mailing list
  devel@lists.fedoraproject.org
  https://admin.fedoraproject.org/mailman/listinfo/devel
  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

- Original Message -
 From: Jiri Vanek jva...@redhat.com
 To: Development discussions related to Fedora 
 devel@lists.fedoraproject.org
 Sent: Thursday, February 26, 2015 9:52:42 AM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On 02/24/2015 05:21 PM, Mikolaj Izdebski wrote:
  On 02/24/2015 04:59 PM, Pete Travis wrote:
  On Feb 24, 2015 8:32 AM, Mikolaj Izdebski mizde...@redhat.com wrote:

  On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
  I would much rather live without any legacy jdk, and if so then
  without any
  rules. But not setting
  them will bring chaos for majority of users.

  I have a question: Is there anybody that stepped in to maintain the
  legacy jdk?
  If there is nobody to maintain it trying to come up with this
  guidelines now would be pointless.
  In short I think that such guidelines would better be created *only*
  when there are interested parties, jointly with them and the process is
  played a bit by some copr repo or similar. Purely theoretical work is not

 This pure theoretical work is based on various troubles various
 multiple/legacy jdks caused in last
 years.  So it is preventing the issues we know will rise.

  needed.

  I fully agree with Alex here.

  I would add that if someone really wants to maintain older JDK in Fedora
  then it should up to *them* to come up with a solution that will work

 Them? ANy packaging/openjdk newbie? Cool. It will break and will breaak a
 lot.

As long as this happens in COPR repo until it's good to go I don't see a 
problem. This will also means that at the time it goes into Fedora we do not 
speak about newbie anymore. 

Alexander Kurtakov
Red Hat Eclipse team

 Those guidelines were written to protect fedora from possible harm.

  and satisfy expectations of JKD maintainers and Java SIG. Maintaining
  package is more than clicking unorphan in pkgdb.

  --
  --

  If some third party supplies 'java' as the $legacy jdk, and the user
  installs a Fedora package built on $current jdk, which provider will win,
  and what packages will break?

 Hopefully none. And the guidelines should prevent any unsuitable jdk to win
 automatically.

  It's implementation detail of different package management systems
  (yum/dnf etc) and in general it's unspecfied. My experience shows that
  multiple packages providing the same thing are unreliable in practice
  and best avoided.

  If the user uses alternatives to set the jdk (that applies here, right?)
  any applications that need one version or the other could break?

 I don't know how to avoid this issue. But at least it will happen - if happen
 at all - after the
 manual switch is done.

  Particular applications can be configured to use different JRE/JDK
  versions (for example you can run Maven with Java 8, but Ant with Java
  7). Per-user configuration is also possible (user bob runs Maven with
  Java 8, but fred with Java 7). Fedora is quite flexible in this aspect.

  Moreover, Fedora can be configured not to use alternatives for Java
  apps, so you can have /usr/bin/java pointing to old JDK while Fedora
  applications are running with default (latest) JDK.

  I understand these are relatively ignorant questions, but if the aim is to
  provide a path for someone to maintain older JDKs it seems better to offer
  them guidelines and best practices instead of you'd better be competent
  enough to figure it out.  They might not think of all the potential
  conflicts.

 Yes, this sounds right.

  If someone wants to maintain old JDK they are free to do so. Moreover,
  they will surely get help from Java SIG with implementing that, provided
  they show enough involvement. But IMO packaging guidelines is not a
 What is an better place?

  place for listing details how compat packages for JDK should look like.

 Java SIG is busy enough. Why to add you more work?

 J.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 08:42 AM, Jiri Vanek wrote:
 Also, my proposal of introducing java metapackage (see my other post
 in this thread), which would always require the latest JDK, solves this
 problem in a different way, without modifying ordinary Java packages
 at all.

 
 May you be more exact with the metapackage? Before I come up with
 legacy, I hoped to solve the issues via some metapackage. At the end I
 gave up, because the touch of user was always necessary.

I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/26/2015 09:20 AM, Mikolaj Izdebski wrote:

On 02/26/2015 08:42 AM, Jiri Vanek wrote:

Also, my proposal of introducing java metapackage (see my other post
in this thread), which would always require the latest JDK, solves this
problem in a different way, without modifying ordinary Java packages
at all.



May you be more exact with the metapackage? Before I come up with
legacy, I hoped to solve the issues via some metapackage. At the end I
gave up, because the touch of user was always necessary.


I described it in much detail in other posts in this thread
(for example message-ID 54eca102.1070...@redhat.com)



Yah. Sorry. I walked across it later then replied this.

However - I'm not convinced that metapackage will work as expected.  If nothing else it will need 
some changes in current infrastructure which I wonted to avoid.



Thanx for that!

J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/26/2015 09:31 AM, Aleksandar Kurtakov wrote:
 If no volunteer shows up for maintenance of old JDK then it would be
 deprecated and obsoleted, as it's was done with previous JDK packages.

 How would that work _exactly_?

 1) JDK maintainers announce deprecation in advance and call for
 volunteers to maintain old JDK

 2) when the time of deprecation comes, JDK package is reassigned to new
 maintainer, if such showed up; no obsoletes are added
 
 We speak about people that are already Fedora packagers, right? Just 
 sponsoring someone that showed up and let him/her maintain legacy JDK in 
 Fedora is recipe for disaster.

Either could work, but new packagers would need to find a sponsor.
I would have no problem sponsoring someone that shows involvement in
Fedora and has good knowledge about JDK internals, for example OpenJDK
upstream developer.

 For not-yet-packagers they would have to go through the full 
 review-sponsoring process.

No package review is necessary to sponsor new packager.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-25 Thread Miloslav Trmač

 On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
  Hello,
  java would be the preferred JRE in Fedora. The package would have no
  content, but it would have Requires on preferred Fedora JRE, currently
  java-1.8.0-openjdk. This could be easily changed as default JRE changes.
  The same is for other binary subpackages of java, respectively.
 
  All system packages would require subpackages of java as they do now
  (unless there is good reason not to). Users that install java would
  get latest JRE, which would be updated to new major versions as they
  become default. Older JDKs would not be removed during update (unless
  there is no maintainer and they are obsoleted as currently),
  
  AFAIK nothing obsoletes a package just because it is orphaned…
 
 If no volunteer shows up for maintenance of old JDK then it would be
 deprecated and obsoleted, as it's was done with previous JDK packages.

How would that work _exactly_?

1. JDK-(N+1) is first shipped.  The maintainer of JDK-N intends not to package 
it, so JDK-(N+1) includes Obsoletes:JDK-N from the start.
2. Someone revives JDK-N.  Oops, it cannot be installed because JDK-(N+1) 
obsoletes it.
3. JDK-(N+1) is updated to remove the Obsoletes: .  Oops, upgrades from older 
Fedora versions will no longer remove JDK-N for users who didn’t ask for the 
legacy version.

This is the problem that the renaming to -legacy is supposed to prevent.  
Though, perhaps it would work equally well to have Obsoletes:JDK-N  
$version-($release+1); this would still allow updating the older Fedora with 
bug fixes for JDK-N but to be removed on upgrade, as long as the $release 
number is kept low enough.  And the possible -legacy package could then be  
represented simply by shipping a version with a bigger $release.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-25 Thread Bruno Wolff III


On Wed, Feb 25, 2015 at 12:58:17 -0500,
 Miloslav Trmač m...@redhat.com wrote:


1. JDK-(N+1) is first shipped.  The maintainer of JDK-N intends not to package 
it, so JDK-(N+1) includes Obsoletes:JDK-N from the start.
2. Someone revives JDK-N.  Oops, it cannot be installed because JDK-(N+1) 
obsoletes it.


If the release is inckuded in the obsoletes, then bringing back the package 
with a higher release will avoid it being obsoleted.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 04:36 PM, Deepak Bhole wrote:

* Mikolaj Izdebski mizde...@redhat.com [2015-02-24 10:12]:

On 02/24/2015 04:06 PM, Deepak Bhole wrote:

* Mikolaj Izdebski mizde...@redhat.com [2015-02-24 09:58]:

On 02/24/2015 03:32 PM, Deepak Bhole wrote:

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:29]:

On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:04]:

On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
[...]

There were several attempts in past like can you please support jdk
7,6...in newer fedoras and we always told no. When come speech about do it
on your own suddenly many questions marks raised up.

The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
the guy is willing to maintain it.


Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
and its successors. You shouldn't arbitrarily block people from
re-introducing an older branch of any package back into Fedora in the
first place.



We have no intention of blocking it. The reason for proposing these
restrictions is that the Fedora Java stack will not work with older
JDKs, therefore we need to make sure that it goes not get installed on
the system unless explicitly requested by someone who knows what they
are doing.


Well, you do that by adding/updating (Build)Requires: in the packages
which won't work otherwise, not by adding Obsoletes:.



That would generally work for most packages, but there is a new JDK
released every 2 years. This means that we would have to change the BR
and Requires for the entire Java stack (100s and 100s of packages) every
2 years, which is non-trivial.


First, we have versioned auto-requires generated during package build.
Explicit requires on java aren't usually needed. If package requires
java  1:1.7 then it is correct - the package can be assumed to work
with older JDK.



While that is true in terms of source compatibility, it will work only
if it is compiled with the older JDK.


Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
packages related to build systems like ant, maven or gradle. This would
cover most cases of building Java packages using latest JDK.



As you stated, it will cover most cases, but not all. More critically,
this does not solve the issue with requirement of 'java' itself.


These few remaining cases can be easily handled by provenpackager as
mass-change.

Also, my proposal of introducing java metapackage (see my other post
in this thread), which would always require the latest JDK, solves this
problem in a different way, without modifying ordinary Java packages at all.



May you be more exact with the metapackage? Before I come up with legacy, I hoped to solve the 
issues via some metapackage. At the end I gave up, because the touch of user was always necessary.


J.


Ah, I had missed that. Yes, the metapackage solution should work to the
same effect. I don't know if we can just call it 'java' though, unless
you are proposing that 'java' provision be removed from current openjdk
packages?

Deepak


--
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 05:04 PM, Mikolaj Izdebski wrote:

On 02/24/2015 04:36 PM, Deepak Bhole wrote:

* Mikolaj Izdebski mizde...@redhat.com [2015-02-24 10:12]:

On 02/24/2015 04:06 PM, Deepak Bhole wrote:

* Mikolaj Izdebski mizde...@redhat.com [2015-02-24 09:58]:

On 02/24/2015 03:32 PM, Deepak Bhole wrote:

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:29]:

On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:04]:

On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
[...]

There were several attempts in past like can you please support jdk
7,6...in newer fedoras and we always told no. When come speech about do it
on your own suddenly many questions marks raised up.

The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
the guy is willing to maintain it.


Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
and its successors. You shouldn't arbitrarily block people from
re-introducing an older branch of any package back into Fedora in the
first place.



We have no intention of blocking it. The reason for proposing these
restrictions is that the Fedora Java stack will not work with older
JDKs, therefore we need to make sure that it goes not get installed on
the system unless explicitly requested by someone who knows what they
are doing.


Well, you do that by adding/updating (Build)Requires: in the packages
which won't work otherwise, not by adding Obsoletes:.



That would generally work for most packages, but there is a new JDK
released every 2 years. This means that we would have to change the BR
and Requires for the entire Java stack (100s and 100s of packages) every
2 years, which is non-trivial.


First, we have versioned auto-requires generated during package build.
Explicit requires on java aren't usually needed. If package requires
java  1:1.7 then it is correct - the package can be assumed to work
with older JDK.



While that is true in terms of source compatibility, it will work only
if it is compiled with the older JDK.


Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
packages related to build systems like ant, maven or gradle. This would
cover most cases of building Java packages using latest JDK.



As you stated, it will cover most cases, but not all. More critically,
this does not solve the issue with requirement of 'java' itself.


These few remaining cases can be easily handled by provenpackager as
mass-change.

Also, my proposal of introducing java metapackage (see my other post
in this thread), which would always require the latest JDK, solves this
problem in a different way, without modifying ordinary Java packages at all.



Ah, I had missed that. Yes, the metapackage solution should work to the
same effect. I don't know if we can just call it 'java' though, unless
you are proposing that 'java' provision be removed from current openjdk
packages?


I'm not really proposing as I haven't thought about this much yet, but
the idea was about be adding a few empty binary packages java,
java-devel, java-headless and so on (they could be subpackages of
javapackages-tools). Existing provides with the same names could be
removed from JDK packages.

java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of java, respectively.

All system packages would require subpackages of java as they do now
(unless there is good reason not to). Users that install java would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently), but users
could remove them with yum autoremove, unless something requires older
JDK or they installed it explicitly.


Does it really seem to you as more simple  solution both for packagers and 
users?

it does snot to me...

J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 05:21 PM, Mikolaj Izdebski wrote:

On 02/24/2015 04:59 PM, Pete Travis wrote:

On Feb 24, 2015 8:32 AM, Mikolaj Izdebski mizde...@redhat.com wrote:

On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:

I would much rather live without any legacy jdk, and if so then

without any

rules. But not setting
them will bring chaos for majority of users.

I have a question: Is there anybody that stepped in to maintain the

legacy jdk?

If there is nobody to maintain it trying to come up with this

guidelines now would be pointless.

In short I think that such guidelines would better be created *only*

when there are interested parties, jointly with them and the process is
played a bit by some copr repo or similar. Purely theoretical work is not

This pure theoretical work is based on various troubles various multiple/legacy jdks caused in last
years. So it is preventing the issues we know will rise.

needed.

I fully agree with Alex here.

I would add that if someone really wants to maintain older JDK in Fedora
then it should up to *them* to come up with a solution that will work

Them? ANy packaging/openjdk newbie? Cool. It will break and will breaak a lot.

Those guidelines were written to protect fedora from possible harm.

and satisfy expectations of JKD maintainers and Java SIG. Maintaining
package is more than clicking unorphan in pkgdb.

--
--

If some third party supplies 'java' as the $legacy jdk, and the user
installs a Fedora package built on $current jdk, which provider will win,
and what packages will break?

Hopefully none. And the guidelines should prevent any unsuitable jdk to win
automatically.

It's implementation detail of different package management systems
(yum/dnf etc) and in general it's unspecfied. My experience shows that
multiple packages providing the same thing are unreliable in practice
and best avoided.

If the user uses alternatives to set the jdk (that applies here, right?)
any applications that need one version or the other could break?

I don't know how to avoid this issue. But at least it will happen - if happen at all - after the
manual switch is done.

Particular applications can be configured to use different JRE/JDK
versions (for example you can run Maven with Java 8, but Ant with Java
7). Per-user configuration is also possible (user bob runs Maven with
Java 8, but fred with Java 7). Fedora is quite flexible in this aspect.

Moreover, Fedora can be configured not to use alternatives for Java
apps, so you can have /usr/bin/java pointing to old JDK while Fedora
applications are running with default (latest) JDK.

I understand these are relatively ignorant questions, but if the aim is to
provide a path for someone to maintain older JDKs it seems better to offer
them guidelines and best practices instead of you'd better be competent
enough to figure it out. They might not think of all the potential
conflicts.

Yes, this sounds right.

If someone wants to maintain old JDK they are free to do so. Moreover,
they will surely get help from Java SIG with implementing that, provided
they show enough involvement. But IMO packaging guidelines is not a

What is an better place?

place for listing details how compat packages for JDK should look like.

Java SIG is busy enough. Why to add you more work?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-25 Thread Aleksandar Kurtakov

- Original Message -
 From: Mikolaj Izdebski mizde...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Wednesday, February 25, 2015 11:14:35 AM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On 02/24/2015 04:06 PM, Jiri Vanek wrote:
  On 02/24/2015 04:03 PM, Mikolaj Izdebski wrote:
  On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote:
  2.) Ensure dist upgrades remove old JDK package (which may no longer
   get security updates).

  Firstly, as I understand upgrade isn't supposed to remove packages by
  default, unless they are obsoleted or conflict with something. Are you
  saying that JDKs should be treated exceptionally by package management
  systems?

  I should add that user can easily remove packages which were installed
  as dependencies, but which are no longer needed by running yum
  autoremove command.

  So by other words - from option one and two you vote for two, no
  renaming, and removing rules 4,5,6,7.

 Technically I'm against this change, see my first post.

  You do not complain about rule 2 and 3.Right?

 Rule 2 is definitely a good thing. Muliple providers of the same thing
 don't work in practice, so we should have only one package providing
 java etc.

 I don't know the exact scheme used for priorites, so I can't comment on
 rule 3. I trust you to set priorities correctly so that main JDK has
 highest priority. Lecacy and tech-preview JDKs should IMO have lower
 priority.

I would even say that legacy(even any) JVMs should not use the alternatives 
system at all. I still remember the fun of having kaffe, jamvm, gcj.. with 
their own priorities, alternatives (java/javac/jar..) going out of sync and 
etc.  This was a nightmare to support and it was causing more damage than 
helping. Using legacy JVM should be done using the tools that provide more 
isolation nowadays like scl to prevent these problems.

Alexander Kurtakov
Red Hat Eclipse team

 --
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-25 Thread Hedayat Vatankhah



/*Mikolaj Izdebski mizde...@redhat.com*/ wrote on Wed, 25 Feb 2015 
10:07:28 +0100:

On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:

However, if there are JAR files which are useful
for a developer, they can have a -legacy version too!

There is no technical reason to suffix anything - you can put JARs that
depend on old version of JDK in /usr/{share,lib}/java-x.y.z, for example
/usr/share/java-1.7.0/ for JARs that require JDK 7.

There is: I'm talking about rpm packages, and you can't install multiple 
rpm packages with the same name simultaneously. So, you'll need to 
change the name. BTW, -legacy was just an example. I'd prefer 'versioned 
package names' as in my proposal for libraries.


Hedayat
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/25/2015 10:55 AM, Hedayat Vatankhah wrote:
 
 /*Mikolaj Izdebski mizde...@redhat.com*/ wrote on Wed, 25 Feb 2015
 10:07:28 +0100:
 On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:
 However, if there are JAR files which are useful
 for a developer, they can have a -legacy version too!
 There is no technical reason to suffix anything - you can put JARs that
 depend on old version of JDK in /usr/{share,lib}/java-x.y.z, for example
 /usr/share/java-1.7.0/ for JARs that require JDK 7.

 There is: I'm talking about rpm packages, and you can't install multiple
 rpm packages with the same name simultaneously. So, you'll need to
 change the name. BTW, -legacy was just an example. I'd prefer 'versioned
 package names' as in my proposal for libraries.

Java compat package names should be suffixed with version, not -legacy
string.
See: http://fedoraproject.org/wiki/Packaging:Java#Compatibility_packages

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:
 However, if there are JAR files which are useful
 for a developer, they can have a -legacy version too!

There is no technical reason to suffix anything - you can put JARs that
depend on old version of JDK in /usr/{share,lib}/java-x.y.z, for example
/usr/share/java-1.7.0/ for JARs that require JDK 7.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 04:06 PM, Jiri Vanek wrote:
 On 02/24/2015 04:03 PM, Mikolaj Izdebski wrote:
 On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote:
 2.) Ensure dist upgrades remove old JDK package (which may no longer
  get security updates).

 Firstly, as I understand upgrade isn't supposed to remove packages by
 default, unless they are obsoleted or conflict with something. Are you
 saying that JDKs should be treated exceptionally by package management
 systems?

 I should add that user can easily remove packages which were installed
 as dependencies, but which are no longer needed by running yum
 autoremove command.

 
 So by other words - from option one and two you vote for two, no
 renaming, and removing rules 4,5,6,7.

Technically I'm against this change, see my first post.

 You do not complain about rule 2 and 3.Right?

Rule 2 is definitely a good thing. Muliple providers of the same thing
don't work in practice, so we should have only one package providing
java etc.

I don't know the exact scheme used for priorites, so I can't comment on
rule 3. I trust you to set priorities correctly so that main JDK has
highest priority. Lecacy and tech-preview JDKs should IMO have lower
priority.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 06:41 PM, Miloslav Trmač wrote:
 Hello,
 java would be the preferred JRE in Fedora. The package would have no
 content, but it would have Requires on preferred Fedora JRE, currently
 java-1.8.0-openjdk. This could be easily changed as default JRE changes.
 The same is for other binary subpackages of java, respectively.

 All system packages would require subpackages of java as they do now
 (unless there is good reason not to). Users that install java would
 get latest JRE, which would be updated to new major versions as they
 become default. Older JDKs would not be removed during update (unless
 there is no maintainer and they are obsoleted as currently),
 
 AFAIK nothing obsoletes a package just because it is orphaned…

If no volunteer shows up for maintenance of old JDK then it would be
deprecated and obsoleted, as it's was done with previous JDK packages.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/25/2015 10:07 AM, Mikolaj Izdebski wrote:

On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:

However, if there are JAR files which are useful
for a developer, they can have a -legacy version too!


There is no technical reason to suffix anything - you can put JARs that
depend on old version of JDK in /usr/{share,lib}/java-x.y.z, for example
/usr/share/java-1.7.0/ for JARs that require JDK 7.

The reason for suffix is to be able properly obsolete, and so protect 99% of users from having also 
old java installed.


I dont know how to technically solve this without obsolete.  In all other scenarios  manual touch of 
user is needed to keep only one (main) jdk.


If you will come with way how to keep 99% of users safe from any legacy jdk  then I wil lbe happy to 
abandon -legacy and go with simple orphaning.


*however* legacy have also one advantage - any user - even unskilled - may easily spot that 
something in his system is using legacy jdk or (after he typed (yum install java-1.*  immediately 
see that something then just simple opened is installed)



J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/25/2015 06:39 AM, Hedayat Vatankhah wrote:

/*Kevin Kofler*/ wrote on Wed, 25 Feb 2015 01:31:59 +0100:

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 Vanekjva...@redhat.com

IMHO, this is not implementable for a simple practical reason: All the JARs
we ship are built from source with our default JDK. They will in general NOT
work on any JRE that's older than the default JDK. (A JRE/JDK that's NEWER
than the default JDK can work though, e.g., the java-1.8.0-openjdk packages
in Fedora 19 and 20. But we were already providing those.)

To avoid state of things you just described, this proposal was described.
Nothing will be compiled or run by legacy jdk if those rules are kept, not even
by accident.

Howevewr people willingly and with full consequence wil be able to use legacy jdk for third party
apps, or go on theirs system on theirs own responsibility.

I'd say this proposal is very similar to my proposal[1] for libraries: the
legacy JDKs can be useful
for the user when facing with non-Fedora development. IMHO, it is fine, and
even great, that no
Fedora JARs will depend on legacy JDK. However, if there are JAR files which
are useful for a
developer, they can have a -legacy version too!

Yes. This is the intention.

Regards,
Hedayat

[1] Proposal to (formally/easily) allowing multiple versions of the same library
installable thread

J,
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Sumit Bhardwaj

Hi All,

I have been reading this mail chain for some time and there is something
I wanted to say. It's kind of a long mail, I apologize for taking so
much of your time but request you to please bear with me. I work as a
technical consultant on IBM WebSphere, IBM BPM, Java/J2EE and Python
technology stacks, who has to code on Java/J2EEquite often as well and I
use Fedora 21 Workstation as my primary OS. My field of work is such
that I need to use JDK versions 1.4, 5, 6, 7 and 8, all from time to
time. This is because as time passed, solutions delivered to customers
were built using incremental versions of Java/J2EE specifications and
were not frequently upgraded. In my role, the changes/fixes I do to
these enterprise apps are usually small and require only a certain jar
file to be recompiled, or in some cases only one class. In such cases,
maintaining binary compatibility is a must and for that I need to
recompile that one jar/class with the original version of JDK that was
used to compile the rest of the project in the first place.

I use Oracle java in most cases due to corporate policies (for personal
use, I use the latest version of OpenJDK). Now as per Oracle's policy,
which I am sure is similar for OpenJDK as well, a particular version of
JDK/JRE is updated till and even some time after the next major version
is released, and then at a certain Update level, Oracle stops supporting
it. That update version becomes the final update for that particular
major release, and is sent into archives, while updates keep on getting
released for the current version.

With Oracle JDK, there are two installation approaches available for RPM
based systems. They provide an RPM package which installs java
in /usr/java, i.e. in system area and the latest installed java version
become default. However, they also provides tarballs of JDKs, that
contain certain standard directory structure of JDK  intact inside one
folder. These tarballs can be extracted and placed in any place on file
system and once JAVA_HOME is pointed towards these+PATH is locally
updated to include it, user can basically use this JDK without any
issues. What version of Java is installed in system as default, in
system area (/usr/java) become irrelevant.

With IDEs like Eclipse and NetBeans the process is even simpler, as you
can define these individual folders as JDKs for particular API versions
in IDE configuration permanently and while creating a project can choose
to use any of these defined JDKs. This is the approach that I take. I
have the last updated versions of all the JDKs from 1.4 to 8 in my /opt
folder. I have these configured in Eclipse and NetBeans for each API
version and I use them all as required by the project.

So I guess if OpenJDK can follow the same approach and can give an
option to download tarballs of older versions and use them in place,
without requiring any installation, as a definite directory structure,
then the problem is solved. There is no need to maintain old version per
se in repositories, as these are not updated anymore and the user will
be able to use multiple versions without conflict of any kind. As for
the default JDK, it can be kept how it is now i.e. The latest available
JDK can be maintained in Fedora repos as they are being maintained now
and updates can be provided for the defined lifetime of that JDK.

Let me know what you guys think about this approach.

-- 
Regards,
Sumit Bhardwaj 

On Tue, 2015-02-24 at 18:22 +0100, Mikolaj Izdebski wrote:

 On 02/24/2015 05:21 PM, Mario Torre wrote:
  On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
  On 02/24/2015 02:15 PM, Jiri Vanek wrote:
  On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
  I am against official guidelines or policy for legacy JDK packages. I
  don't think that any such policy is needed and it would only encourage
  adoption of old packages for which there might be no security updates.
 
  Well thats the point - people are calling for them. And wont to maintain
  them with this risk.
 
  I thought that the point of this change proposal was enabling community
  to maintain legacy JDKs, not encouraging people to package them without
  good reason or without involvement to truly maintaining them. Packaging
  older JDKs is *already* possible, so IMHO this change accomplishes
  nothing but showing people how they can dump old, unmaintained software
  into Fedora.
  
  Well, in this case it would not be un-maintained, the Fedora package
  would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
  are still actively contributing to the upstream software in its various
  versions. While you as a packager cannot specifically count on that,
  there's still a level of confidence that the base software won't be
  abandoned any time soon. And even when we will stop supporting those
  older versions, the community will take over if there is a need for
  that, exactly like we have done ourselves before.
  
  Indeed, there's an overhead

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

2015-02-24 Thread Jaroslav Reznik

= Proposed System Wide Change: Legacy implementations of the Java platform in 
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora

Change owner(s): Jiri Vanek jva...@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 overorpahned 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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce

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

2015-02-24 Thread Jaroslav Reznik

= Proposed System Wide Change: Legacy implementations of the Java platform in 
Fedora =
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora

Change owner(s): Jiri Vanek jva...@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 overorpahned 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-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

I am against official guidelines or policy for legacy JDK packages. I
don't think that any such policy is needed and it would only encourage
adoption of old packages for which there might be no security updates.

Of course package maintainers can agree on specific rules that apply to
their packages, but it doesn't mean that such rules should be part of
packaging guidelines.

More details inline. My counter-proposal is at the end.

On 02/24/2015 10:34 AM, Jaroslav Reznik wrote:
 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.

Currently anyone is allowed to maintain legacy JDKs in Fedora according
to general rules, so this change proposal does not enable maintenance
of legacy JDKs.

 === Proposed rules ===
 0. '''Main JDK maintainers are not never ever responsible for any legacy jdk. 
 This must remain clear'''

Package maintainers are responsible for their packages. If maintainer of
main JDK is also maintaining legacy JDK then (s)he should be
responsible for both of them. I don't see why any special rule should be
defined.

  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

Fedora already supports multiple JDKs installable in parallel. This was
inherited from JPackage project. This breaks long-established rule of
naming JDK packages as java-x.y.z-vendor used across different
distributions (JPackage, Fedora, RHEL, SUSE, ...)

 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)

Again, I don't think we should define such rule. Package owner decides
who can be comaintainer. I don't think we should prevent someone from
maintaining package in Fedora just because he doesn't want main JDK
maintainers to comaintain his package or enforce anyone to be
comaintainer without his/her will. Interested parties can always
volunteer to become comaintainers or watch for changes, report bugs and
propose fixes or enhancements.

 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 overorpahned 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)

Currently all compat packages must complete full review before being
introduced. Why JDK should be treated specially? I think that with
complex system of virtual provides, alternatives and strict directory
layout it's necessary to fully review legacy JDK package to make sure
it doesn't conflict with primary JDK and that it is integrated with
Fedora as expected.

 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. 

I don't like this rule either. In some cases it may be useful or
necessary to require specific JDK or JRE package. For example
icedtea-web requires java-1.8.0-openjdk, which is correct and should not
be changed.


As counter-proposal I recommend starting discussion within Java SIG on
how to handle JDK deprecation. The end result could be documenting what
was agreed somewhere on the wiki.

I imagine the process of deprecating JDK could look like:
1) announce deprecation in advance and call for volunteers
2) if there are volunteers to maintain old JDK then handover package to
them, discussing packaging details of the old JDK (package naming,
provides, alternatives and so on) and possibly help with the process
3) if no volunteer shows up then retire old JDK package

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Dominik 'Rathann' Mierzejewski

On Tuesday, 24 February 2015 at 13:34, Severin Gehwolf wrote:
 On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
 [...]
    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
  
  Fedora already supports multiple JDKs installable in parallel. This was
  inherited from JPackage project. This breaks long-established rule of
  naming JDK packages as java-x.y.z-vendor used across different
  distributions (JPackage, Fedora, RHEL, SUSE, ...)
 [...]
 
 The idea behind this -legacy suffix was to ensure a reasonable upgrade
 path for people *only* using default java-x.y.z-openjdk package. 
 
 Consider the following scenario (all hypothetical, not saying that any
 Fedora releases and JDK releases align in this way):
 
 F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
 java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
 The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
 java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
 java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
 that no old JDKs stick around on the majority of Fedora systems.
 
 If the name was kept there does not seem to be a good way to:
 1.) Ensure dist upgrades update JDK packages
 2.) Ensure dist upgrades remove old JDK package (which may no longer
 get security updates).
 
 Do you see a way to achieve this without a name change of the package?

Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk
are different packages?

If there are any packages requiring java-1.8.0-openjdk they can keep
using it as long as it has a maintainer. java-1.9.0-openjdk will be
a completely new package.

I agree with Mikołaj that there's no need for what you're proposing.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 01:34 PM, Severin Gehwolf wrote:

On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
[...]

 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


Fedora already supports multiple JDKs installable in parallel. This was
inherited from JPackage project. This breaks long-established rule of
naming JDK packages as java-x.y.z-vendor used across different
distributions (JPackage, Fedora, RHEL, SUSE, ...)

[...]

The idea behind this -legacy suffix was to ensure a reasonable upgrade
path for people *only* using default java-x.y.z-openjdk package.

Consider the following scenario (all hypothetical, not saying that any
Fedora releases and JDK releases align in this way):

F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
that no old JDKs stick around on the majority of Fedora systems.

If the name was kept there does not seem to be a good way to:
1.) Ensure dist upgrades update JDK packages
2.) Ensure dist upgrades remove old JDK package (which may no longer
 get security updates).

Do you see a way to achieve this without a name change of the package?



Unluckily, I'm not.

But I guess, this question is going to Mikolaj.


J.



--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Severin Gehwolf

On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
[...]
   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
 
 Fedora already supports multiple JDKs installable in parallel. This was
 inherited from JPackage project. This breaks long-established rule of
 naming JDK packages as java-x.y.z-vendor used across different
 distributions (JPackage, Fedora, RHEL, SUSE, ...)
[...]

The idea behind this -legacy suffix was to ensure a reasonable upgrade
path for people *only* using default java-x.y.z-openjdk package. 

Consider the following scenario (all hypothetical, not saying that any
Fedora releases and JDK releases align in this way):

F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
that no old JDKs stick around on the majority of Fedora systems.

If the name was kept there does not seem to be a good way to:
1.) Ensure dist upgrades update JDK packages
2.) Ensure dist upgrades remove old JDK package (which may no longer
get security updates).

Do you see a way to achieve this without a name change of the package?

Cheers,
Severin


 -- 
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk



-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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



Package maintainers are responsible for their packages. If maintainer of
main JDK is also maintaining legacy JDK then (s)he should be
responsible for both of them. I don't see why any special rule should be
defined.

You missed very  important point. The maintainer will never be same. We (people around OpenJDK 
packages) are not going to do so.



J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 01:50 PM, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 24 February 2015 at 13:34, Severin Gehwolf wrote:

On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
[...]

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

Fedora already supports multiple JDKs installable in parallel. This was
inherited from JPackage project. This breaks long-established rule of
naming JDK packages as java-x.y.z-vendor used across different
distributions (JPackage, Fedora, RHEL, SUSE, ...)

[...]

The idea behind this -legacy suffix was to ensure a reasonable upgrade
path for people *only* using default java-x.y.z-openjdk package.

Consider the following scenario (all hypothetical, not saying that any
Fedora releases and JDK releases align in this way):

F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
that no old JDKs stick around on the majority of Fedora systems.

If the name was kept there does not seem to be a good way to:
1.) Ensure dist upgrades update JDK packages
2.) Ensure dist upgrades remove old JDK package (which may no longer
get security updates).

Do you see a way to achieve this without a name change of the package?

Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk
are different packages?

yes they are, but the secon *is* update of first.

If there are any packages requiring java-1.8.0-openjdk they can keep
using it as long as it has a maintainer. java-1.9.0-openjdk will be
a completely new package.

Yes they can. But until now it was really bad idea.

IcedTea-Web was also wrong example - it is requiring *main* jdk. Nothing else.

And as it is not strightforward to compile ITW agains different jdks, then the
strict rule have sense.

I agree with Mikołaj that there's no need for what you're proposing.

There is. Not using those rules will completly break fedaora+java as we know
it now.

I would much rather live without any legacy jdk, and if so then without any rules. But not setting
them will bring chaos for majority of users.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:

I am against official guidelines or policy for legacy JDK packages. I
don't think that any such policy is needed and it would only encourage
adoption of old packages for which there might be no security updates.


Well thats the point - people are calling for them. And wont to maintain them 
with this risk.

Those rules are here to protect the rest - who dont need legacy jdk for daily 
useage.


Of course package maintainers can agree on specific rules that apply to
their packages, but it doesn't mean that such rules should be part of
packaging guidelines.

More details inline. My counter-proposal is at the end.

On 02/24/2015 10:34 AM, Jaroslav Reznik wrote:

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.


Currently anyone is allowed to maintain legacy JDKs in Fedora according
to general rules, so this change proposal does not enable maintenance
of legacy JDKs.


It is not true. We were killing old packages withut handling the owenership or maintainerships to 
others.





=== Proposed rules ===
0. '''Main JDK maintainers are not never ever responsible for any legacy jdk.
This must remain clear'''


Package maintainers are responsible for their packages. If maintainer of
main JDK is also maintaining legacy JDK then (s)he should be
responsible for both of them. I don't see why any special rule should be
defined.


As I higlighted - we - main jdk team - are never ever going to do so.



 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


Fedora already supports multiple JDKs installable in parallel. This was
inherited from JPackage project. This breaks long-established rule of
naming JDK packages as java-x.y.z-vendor used across different
distributions (JPackage, Fedora, RHEL, SUSE, ...)


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)


Again, I don't think we should define such rule. Package owner decides
who can be comaintainer. I don't think we should prevent someone from
maintaining package in Fedora just because he doesn't want main JDK
maintainers to comaintain his package or enforce anyone to be
comaintainer without his/her will. Interested parties can always
volunteer to become comaintainers or watch for changes, report bugs and
propose fixes or enhancements.


I do not insists on this rule. But it is the only way how to be sure the those rules are kept or to 
act quickly if something breaks.


It is actually good will of openjdk team that we are willing to do so.

I will happily give up on it.



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 overorpahned 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)


Currently all compat packages must complete full review before being
introduced. Why JDK should be treated specially? I think that with
complex system of virtual provides, alternatives and strict directory
layout it's necessary to fully review legacy JDK package to make sure
it doesn't conflict with primary JDK and that it is integrated with
Fedora as expected.


Well the jdk - as is now - will never pass regular review - it is handling config files and 
libraries and shared jars really differently - and have good purposes for it.



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.


I don't like this rule either. In some cases it may be useful or
necessary to require specific JDK or JRE package. For example
icedtea-web requires java-1.8.0-openjdk, which is correct and should not
be changed.


All packages are requiring java or java-headless or java-devel. The exeptions are rare. ITW actually 
do not need this, but it making my life easier. So I will turn to java or ask for exception. In case 
of trnsition to  jdk9,  I will *not* kepp java-1.8.0-openjdk unless something terrible happens.



As counter-proposal I recommend starting discussion within Java SIG on
how to handle JDK deprecation. The end result could be documenting what
was agreed somewhere on the wiki.


This one have issue to add much more work to people already taking

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

On 02/24/2015 01:34 PM, Severin Gehwolf wrote:
 On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
 [...]
  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

 Fedora already supports multiple JDKs installable in parallel. This was
 inherited from JPackage project. This breaks long-established rule of
 naming JDK packages as java-x.y.z-vendor used across different
 distributions (JPackage, Fedora, RHEL, SUSE, ...)
 [...]
 
 The idea behind this -legacy suffix was to ensure a reasonable upgrade
 path for people *only* using default java-x.y.z-openjdk package. 
 
 Consider the following scenario (all hypothetical, not saying that any
 Fedora releases and JDK releases align in this way):
 
 F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
 java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
 The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
 java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
 java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
 that no old JDKs stick around on the majority of Fedora systems.
 
 If the name was kept there does not seem to be a good way to:
 1.) Ensure dist upgrades update JDK packages

That should be possible to achieve without renaming JDK packages. I
haven't considered all options, but one of several possibilities is
creating java package that would require the latest JDK/JRE. If user
installs java then it will be updated to latest version when it
becomes available, but if user installs java-1.8.0-openjdk then it
won't be updated as user explicitly asked for 1.8.0.

 2.) Ensure dist upgrades remove old JDK package (which may no longer
 get security updates).

Firstly, as I understand upgrade isn't supposed to remove packages by
default, unless they are obsoleted or conflict with something. Are you
saying that JDKs should be treated exceptionally by package management
systems?

Secondly, if the old JDK is still maintained by someone then I don't see
a problem with leaving it installed - it shouldn't be used by default
unless user explicitly configured it as default. This is standard
behavior of PMS and at least that's what I would expect as user. (If old
JDK is not maintained any longer then it would be obsoleted and removed
during update.)

 Do you see a way to achieve this without a name change of the package?

I see some ways to achieve 1) without 2), but I don't think that 2) is
necessary or expected by users.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 04:03 PM, Mikolaj Izdebski wrote:

On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote:

2.) Ensure dist upgrades remove old JDK package (which may no longer
 get security updates).


Firstly, as I understand upgrade isn't supposed to remove packages by
default, unless they are obsoleted or conflict with something. Are you
saying that JDKs should be treated exceptionally by package management
systems?


I should add that user can easily remove packages which were installed
as dependencies, but which are no longer needed by running yum
autoremove command.



So by other words - from option one and two you vote for two, no renaming, and removing rules 
4,5,6,7.


You do not complain about rule 2 and 3.Right?
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

* Mikolaj Izdebski mizde...@redhat.com [2015-02-24 09:58]:
 On 02/24/2015 03:32 PM, Deepak Bhole wrote:
  * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
  09:29]:
  On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
  * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
  09:04]:
  On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
  [...]
  There were several attempts in past like can you please support jdk
  7,6...in newer fedoras and we always told no. When come speech about 
  do it
  on your own suddenly many questions marks raised up.
 
  The last open bug is: 
  https://bugzilla.redhat.com/show_bug.cgi?id=1190137
  the guy is willing to maintain it.
 
  Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
  and its successors. You shouldn't arbitrarily block people from
  re-introducing an older branch of any package back into Fedora in the
  first place.
 
 
  We have no intention of blocking it. The reason for proposing these
  restrictions is that the Fedora Java stack will not work with older
  JDKs, therefore we need to make sure that it goes not get installed on
  the system unless explicitly requested by someone who knows what they
  are doing.
 
  Well, you do that by adding/updating (Build)Requires: in the packages
  which won't work otherwise, not by adding Obsoletes:.
 
  
  That would generally work for most packages, but there is a new JDK
  released every 2 years. This means that we would have to change the BR
  and Requires for the entire Java stack (100s and 100s of packages) every
  2 years, which is non-trivial.
 
 First, we have versioned auto-requires generated during package build.
 Explicit requires on java aren't usually needed. If package requires
 java  1:1.7 then it is correct - the package can be assumed to work
 with older JDK.
 

While that is true in terms of source compatibility, it will work only
if it is compiled with the older JDK.

 Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
 packages related to build systems like ant, maven or gradle. This would
 cover most cases of building Java packages using latest JDK.
 

As you stated, it will cover most cases, but not all. More critically,
this does not solve the issue with requirement of 'java' itself.

Deepak

 -- 
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 04:06 PM, Deepak Bhole wrote:
 * Mikolaj Izdebski mizde...@redhat.com [2015-02-24 09:58]:
 On 02/24/2015 03:32 PM, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
 09:29]:
 On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
 09:04]:
 On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
 [...]
 There were several attempts in past like can you please support jdk
 7,6...in newer fedoras and we always told no. When come speech about 
 do it
 on your own suddenly many questions marks raised up.

 The last open bug is: 
 https://bugzilla.redhat.com/show_bug.cgi?id=1190137
 the guy is willing to maintain it.

 Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
 and its successors. You shouldn't arbitrarily block people from
 re-introducing an older branch of any package back into Fedora in the
 first place.


 We have no intention of blocking it. The reason for proposing these
 restrictions is that the Fedora Java stack will not work with older
 JDKs, therefore we need to make sure that it goes not get installed on
 the system unless explicitly requested by someone who knows what they
 are doing.

 Well, you do that by adding/updating (Build)Requires: in the packages
 which won't work otherwise, not by adding Obsoletes:.


 That would generally work for most packages, but there is a new JDK
 released every 2 years. This means that we would have to change the BR
 and Requires for the entire Java stack (100s and 100s of packages) every
 2 years, which is non-trivial.

 First, we have versioned auto-requires generated during package build.
 Explicit requires on java aren't usually needed. If package requires
 java  1:1.7 then it is correct - the package can be assumed to work
 with older JDK.

 
 While that is true in terms of source compatibility, it will work only
 if it is compiled with the older JDK.
 
 Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
 packages related to build systems like ant, maven or gradle. This would
 cover most cases of building Java packages using latest JDK.

 
 As you stated, it will cover most cases, but not all. More critically,
 this does not solve the issue with requirement of 'java' itself.

These few remaining cases can be easily handled by provenpackager as
mass-change.

Also, my proposal of introducing java metapackage (see my other post
in this thread), which would always require the latest JDK, solves this
problem in a different way, without modifying ordinary Java packages at all.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
 I would much rather live without any legacy jdk, and if so then without any
 rules. But not setting
 them will bring chaos for majority of users.
 
 I have a question: Is there anybody that stepped in to maintain the legacy 
 jdk? 
 If there is nobody to maintain it trying to come up with this guidelines now 
 would be pointless. 
 In short I think that such guidelines would better be created *only* when 
 there are interested parties, jointly with them and the process is played a 
 bit by some copr repo or similar. Purely theoretical work is not needed.  

I fully agree with Alex here.

I would add that if someone really wants to maintain older JDK in Fedora
then it should up to *them* to come up with a solution that will work
and satisfy expectations of JKD maintainers and Java SIG. Maintaining
package is more than clicking unorphan in pkgdb.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

* Mikolaj Izdebski mizde...@redhat.com [2015-02-24 10:12]:
 On 02/24/2015 04:06 PM, Deepak Bhole wrote:
  * Mikolaj Izdebski mizde...@redhat.com [2015-02-24 09:58]:
  On 02/24/2015 03:32 PM, Deepak Bhole wrote:
  * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
  09:29]:
  On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
  * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
  09:04]:
  On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
  [...]
  There were several attempts in past like can you please support jdk
  7,6...in newer fedoras and we always told no. When come speech about 
  do it
  on your own suddenly many questions marks raised up.
 
  The last open bug is: 
  https://bugzilla.redhat.com/show_bug.cgi?id=1190137
  the guy is willing to maintain it.
 
  Fine, so let him do it and drop the Obsoletes: tag in 
  java-1.8.0-openjdk
  and its successors. You shouldn't arbitrarily block people from
  re-introducing an older branch of any package back into Fedora in the
  first place.
 
 
  We have no intention of blocking it. The reason for proposing these
  restrictions is that the Fedora Java stack will not work with older
  JDKs, therefore we need to make sure that it goes not get installed on
  the system unless explicitly requested by someone who knows what they
  are doing.
 
  Well, you do that by adding/updating (Build)Requires: in the packages
  which won't work otherwise, not by adding Obsoletes:.
 
 
  That would generally work for most packages, but there is a new JDK
  released every 2 years. This means that we would have to change the BR
  and Requires for the entire Java stack (100s and 100s of packages) every
  2 years, which is non-trivial.
 
  First, we have versioned auto-requires generated during package build.
  Explicit requires on java aren't usually needed. If package requires
  java  1:1.7 then it is correct - the package can be assumed to work
  with older JDK.
 
  
  While that is true in terms of source compatibility, it will work only
  if it is compiled with the older JDK.
  
  Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
  packages related to build systems like ant, maven or gradle. This would
  cover most cases of building Java packages using latest JDK.
 
  
  As you stated, it will cover most cases, but not all. More critically,
  this does not solve the issue with requirement of 'java' itself.
 
 These few remaining cases can be easily handled by provenpackager as
 mass-change.
 
 Also, my proposal of introducing java metapackage (see my other post
 in this thread), which would always require the latest JDK, solves this
 problem in a different way, without modifying ordinary Java packages at all.
 

Ah, I had missed that. Yes, the metapackage solution should work to the
same effect. I don't know if we can just call it 'java' though, unless
you are proposing that 'java' provision be removed from current openjdk
packages?

Deepak

 -- 
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 03:51 PM, Mikolaj Izdebski wrote:
 2.) Ensure dist upgrades remove old JDK package (which may no longer
 get security updates).
 
 Firstly, as I understand upgrade isn't supposed to remove packages by
 default, unless they are obsoleted or conflict with something. Are you
 saying that JDKs should be treated exceptionally by package management
 systems?

I should add that user can easily remove packages which were installed
as dependencies, but which are no longer needed by running yum
autoremove command.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 03:32 PM, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:29]:
 On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
 09:04]:
 On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
 [...]
 There were several attempts in past like can you please support jdk
 7,6...in newer fedoras and we always told no. When come speech about do 
 it
 on your own suddenly many questions marks raised up.

 The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
 the guy is willing to maintain it.

 Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
 and its successors. You shouldn't arbitrarily block people from
 re-introducing an older branch of any package back into Fedora in the
 first place.


 We have no intention of blocking it. The reason for proposing these
 restrictions is that the Fedora Java stack will not work with older
 JDKs, therefore we need to make sure that it goes not get installed on
 the system unless explicitly requested by someone who knows what they
 are doing.

 Well, you do that by adding/updating (Build)Requires: in the packages
 which won't work otherwise, not by adding Obsoletes:.

 
 That would generally work for most packages, but there is a new JDK
 released every 2 years. This means that we would have to change the BR
 and Requires for the entire Java stack (100s and 100s of packages) every
 2 years, which is non-trivial.

First, we have versioned auto-requires generated during package build.
Explicit requires on java aren't usually needed. If package requires
java  1:1.7 then it is correct - the package can be assumed to work
with older JDK.

Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
packages related to build systems like ant, maven or gradle. This would
cover most cases of building Java packages using latest JDK.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Dominik 'Rathann' Mierzejewski

On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
[...]
 There were several attempts in past like can you please support jdk
 7,6...in newer fedoras and we always told no. When come speech about do it
 on your own suddenly many questions marks raised up.
 
 The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
 the guy is willing to maintain it.

Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
and its successors. You shouldn't arbitrarily block people from
re-introducing an older branch of any package back into Fedora in the
first place.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Dominik 'Rathann' Mierzejewski

On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:04]:
  On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
  [...]
   There were several attempts in past like can you please support jdk
   7,6...in newer fedoras and we always told no. When come speech about do 
   it
   on your own suddenly many questions marks raised up.
   
   The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
   the guy is willing to maintain it.
  
  Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
  and its successors. You shouldn't arbitrarily block people from
  re-introducing an older branch of any package back into Fedora in the
  first place.
  
 
 We have no intention of blocking it. The reason for proposing these
 restrictions is that the Fedora Java stack will not work with older
 JDKs, therefore we need to make sure that it goes not get installed on
 the system unless explicitly requested by someone who knows what they
 are doing.

Well, you do that by adding/updating (Build)Requires: in the packages
which won't work otherwise, not by adding Obsoletes:.

Regards,
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
Faith manages.
-- Delenn to Lennier in Babylon 5:Confessions and Lamentations
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 02:58 PM, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
[...]

There were several attempts in past like can you please support jdk
7,6...in newer fedoras and we always told no. When come speech about do it
on your own suddenly many questions marks raised up.

The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
the guy is willing to maintain it.


Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
and its successors. You shouldn't arbitrarily block people from
re-introducing an older branch of any package back into Fedora in the
first place.

We can not do it. It will keep legacy jdks in users system. We don't wont  99% of users to keep 
(unwillingly and unknowingly) old jdks. 99% of users is hepy with one - main - jdk. To provide new 
jdk , we have to obsolate old jdk...


If you have workaround for this, please share. (Sewerin already higlighted it 
on devel discussion).


J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 02:15 PM, Jiri Vanek wrote:
 On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
 I am against official guidelines or policy for legacy JDK packages. I
 don't think that any such policy is needed and it would only encourage
 adoption of old packages for which there might be no security updates.
 
 Well thats the point - people are calling for them. And wont to maintain
 them with this risk.

I thought that the point of this change proposal was enabling community
to maintain legacy JDKs, not encouraging people to package them without
good reason or without involvement to truly maintaining them. Packaging
older JDKs is *already* possible, so IMHO this change accomplishes
nothing but showing people how they can dump old, unmaintained software
into Fedora.

 Currently anyone is allowed to maintain legacy JDKs in Fedora according
 to general rules, so this change proposal does not enable maintenance
 of legacy JDKs.
 
 It is not true. We were killing old packages withut handling the
 owenership or maintainerships to others.

Why this is not true? What prevents me from reviving java-1.6.0-openjdk
or java-1.7.0-openjdk in Fedora and making it available in rawhide? If I
wanted could just follow standard process and bring it back any time.

 === Proposed rules ===
 0. '''Main JDK maintainers are not never ever responsible for any
 legacy jdk.
 This must remain clear'''

 Package maintainers are responsible for their packages. If maintainer of
 main JDK is also maintaining legacy JDK then (s)he should be
 responsible for both of them. I don't see why any special rule should be
 defined.
 
 As I higlighted - we - main jdk team - are never ever going to do so.

Imagine that someone become comaintainer of main JDK. This rule would
prevent him from maintaining (and being responsible) for older JDK.
This limits people's freedom and that's why I am against that.

 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 overorpahned 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)

 Currently all compat packages must complete full review before being
 introduced. Why JDK should be treated specially? I think that with
 complex system of virtual provides, alternatives and strict directory
 layout it's necessary to fully review legacy JDK package to make sure
 it doesn't conflict with primary JDK and that it is integrated with
 Fedora as expected.
 
 Well the jdk - as is now - will never pass regular review - it is
 handling config files and libraries and shared jars really differently -
 and have good purposes for it.

Package that doesn't pass review shouldn't be part of Fedora.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Aleksandar Kurtakov

- Original Message -
 From: Jiri Vanek jva...@redhat.com
 To: devel@lists.fedoraproject.org
 Sent: Tuesday, February 24, 2015 3:02:38 PM
 Subject: Re: F22 System Wide Change: Legacy implementations of the Java   
 platform in Fedora

 On 02/24/2015 01:50 PM, Dominik 'Rathann' Mierzejewski wrote:
  On Tuesday, 24 February 2015 at 13:34, Severin Gehwolf wrote:
  On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
  [...]
   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

  Fedora already supports multiple JDKs installable in parallel. This was
  inherited from JPackage project. This breaks long-established rule of
  naming JDK packages as java-x.y.z-vendor used across different
  distributions (JPackage, Fedora, RHEL, SUSE, ...)
  [...]

  The idea behind this -legacy suffix was to ensure a reasonable upgrade
  path for people *only* using default java-x.y.z-openjdk package.

  Consider the following scenario (all hypothetical, not saying that any
  Fedora releases and JDK releases align in this way):

  F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
  java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
  The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
  java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
  java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
  that no old JDKs stick around on the majority of Fedora systems.

  If the name was kept there does not seem to be a good way to:
  1.) Ensure dist upgrades update JDK packages
  2.) Ensure dist upgrades remove old JDK package (which may no longer
   get security updates).

  Do you see a way to achieve this without a name change of the package?

  Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk
  are different packages?

 yes they are, but the secon *is* update of first.

  If there are any packages requiring java-1.8.0-openjdk they can keep
  using it as long as it has a maintainer. java-1.9.0-openjdk will be
  a completely new package.

 Yes they can. But until now it was really bad idea.

 IcedTea-Web was also wrong example - it is requiring *main* jdk. Nothing
 else.

 And as it is not strightforward to compile ITW agains different jdks, then
 the strict rule have sense.

  I agree with Mikołaj that there's no need for what you're proposing.

 There is.  Not using those rules will completly break fedaora+java as we know
 it now.

 I would much rather live without any legacy jdk, and if so then without any
 rules. But not setting
 them will bring chaos for majority of users.

I have a question: Is there anybody that stepped in to maintain the legacy jdk? 
If there is nobody to maintain it trying to come up with this guidelines now 
would be pointless. 
In short I think that such guidelines would better be created *only* when there 
are interested parties, jointly with them and the process is played a bit by 
some copr repo or similar. Purely theoretical work is not needed.  

Alexander Kurtakov
Red Hat Eclipse team

 J.

 --
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:

- Original Message -

From: Jiri Vanek jva...@redhat.com
To: devel@lists.fedoraproject.org
Sent: Tuesday, February 24, 2015 3:02:38 PM
Subject: Re: F22 System Wide Change: Legacy implementations of the Java 
platform in Fedora

On 02/24/2015 01:50 PM, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 24 February 2015 at 13:34, Severin Gehwolf wrote:

On Tue, 2015-02-24 at 12:43 +0100, Mikolaj Izdebski wrote:
[...]

 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

Fedora already supports multiple JDKs installable in parallel. This was
inherited from JPackage project. This breaks long-established rule of
naming JDK packages as java-x.y.z-vendor used across different
distributions (JPackage, Fedora, RHEL, SUSE, ...)

[...]

The idea behind this -legacy suffix was to ensure a reasonable upgrade
path for people *only* using default java-x.y.z-openjdk package.

Consider the following scenario (all hypothetical, not saying that any
Fedora releases and JDK releases align in this way):

F22 has default JDK of java-1.8.0-openjdk. Then, F23 will get
java-1.9.0-openjdk as default and F24 java-1.10.0-openjdk as default.
The upgrade from F22 = F23 will install java-1.9.0-openjdk and remove
java-1.8.0-openjdk. Similarly, the upgrade from F23 to F24 will install
java-1.10.0-openjdk and remove java-1.9.0-openjdk. This is to ensure
that no old JDKs stick around on the majority of Fedora systems.

If the name was kept there does not seem to be a good way to:
1.) Ensure dist upgrades update JDK packages
2.) Ensure dist upgrades remove old JDK package (which may no longer
  get security updates).

Do you see a way to achieve this without a name change of the package?

Wait. Don't you realize that java-1.8.0-openjdk and java-1.9.0-openjdk
are different packages?

yes they are, but the secon *is* update of first.

If there are any packages requiring java-1.8.0-openjdk they can keep
using it as long as it has a maintainer. java-1.9.0-openjdk will be
a completely new package.

Yes they can. But until now it was really bad idea.

IcedTea-Web was also wrong example - it is requiring *main* jdk. Nothing
else.

And as it is not strightforward to compile ITW agains different jdks, then
the strict rule have sense.

I agree with Mikołaj that there's no need for what you're proposing.

There is.  Not using those rules will completly break fedaora+java as we know
it now.

I would much rather live without any legacy jdk, and if so then without any
rules. But not setting
them will bring chaos for majority of users.

I have a question: Is there anybody that stepped in to maintain the legacy jdk?
If there is nobody to maintain it trying to come up with this guidelines now 
would be pointless.
In short I think that such guidelines would better be created *only* when there 
are interested parties, jointly with them and the process is played a bit by 
some copr repo or similar. Purely theoretical work is not needed.

There were several attempts in past like can you please support jdk 7,6...in newer fedoras and we 
always told no. When come speech about do it on your own suddenly many questions marks raised up.

The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137 the guy is willing to 
maintain it.

So deciding that legacy jdks are not never ever supportable, is also option.
Then we will move all users to that statement, and we will let them do theirs 
builds in copr...

Yes its possibility. It is actually the simplest one, but maybe not the 
generally desired one.

J.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:04]:
 On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
 [...]
  There were several attempts in past like can you please support jdk
  7,6...in newer fedoras and we always told no. When come speech about do it
  on your own suddenly many questions marks raised up.
  
  The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
  the guy is willing to maintain it.
 
 Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
 and its successors. You shouldn't arbitrarily block people from
 re-introducing an older branch of any package back into Fedora in the
 first place.
 

We have no intention of blocking it. The reason for proposing these
restrictions is that the Fedora Java stack will not work with older
JDKs, therefore we need to make sure that it goes not get installed on
the system unless explicitly requested by someone who knows what they
are doing.

Deepak

 Regards,
 Dominik
 -- 
 Fedora http://fedoraproject.org/wiki/User:Rathann
 RPMFusion http://rpmfusion.org
 Faith manages.
 -- Delenn to Lennier in Babylon 5:Confessions and Lamentations
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:29]:
 On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
  * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
  09:04]:
   On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
   [...]
There were several attempts in past like can you please support jdk
7,6...in newer fedoras and we always told no. When come speech about 
do it
on your own suddenly many questions marks raised up.

The last open bug is: 
https://bugzilla.redhat.com/show_bug.cgi?id=1190137
the guy is willing to maintain it.
   
   Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
   and its successors. You shouldn't arbitrarily block people from
   re-introducing an older branch of any package back into Fedora in the
   first place.
   
  
  We have no intention of blocking it. The reason for proposing these
  restrictions is that the Fedora Java stack will not work with older
  JDKs, therefore we need to make sure that it goes not get installed on
  the system unless explicitly requested by someone who knows what they
  are doing.
 
 Well, you do that by adding/updating (Build)Requires: in the packages
 which won't work otherwise, not by adding Obsoletes:.
 

That would generally work for most packages, but there is a new JDK
released every 2 years. This means that we would have to change the BR
and Requires for the entire Java stack (100s and 100s of packages) every
2 years, which is non-trivial.

Deepak

 Regards,
 -- 
 Fedora http://fedoraproject.org/wiki/User:Rathann
 RPMFusion http://rpmfusion.org
 Faith manages.
 -- Delenn to Lennier in Babylon 5:Confessions and Lamentations
 -- 
 devel mailing list
 devel@lists.fedoraproject.org
 https://admin.fedoraproject.org/mailman/listinfo/devel
 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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


On 02/24/2015 03:11 PM, Dominik 'Rathann' Mierzejewski wrote:

On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:

* Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 09:04]:

On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
[...]

There were several attempts in past like can you please support jdk
7,6...in newer fedoras and we always told no. When come speech about do it
on your own suddenly many questions marks raised up.

The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
the guy is willing to maintain it.


Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
and its successors. You shouldn't arbitrarily block people from
re-introducing an older branch of any package back into Fedora in the
first place.



We have no intention of blocking it. The reason for proposing these
restrictions is that the Fedora Java stack will not work with older
JDKs, therefore we need to make sure that it goes not get installed on
the system unless explicitly requested by someone who knows what they
are doing.


Well, you do that by adding/updating (Build)Requires: in the packages
which won't work otherwise, not by adding Obsoletes:.


No. They are (B)R java. We are obsoleting older version of java and doing mass rebuild. Thats the 
only way how to ensure whole stack is build by same jdk - main  jdk - and we need to ensure 99% of 
people will be using the correct jdk with correct application


I probably miss your point, you seems to be unaware about haw java udates and 
stack is working

best regards from cz,

  J.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Mario Torre

On Tue, 2015-02-24 at 15:19 +0100, Jiri Vanek wrote:
 On 02/24/2015 02:58 PM, Dominik 'Rathann' Mierzejewski wrote:
  On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
  [...]
  There were several attempts in past like can you please support jdk
  7,6...in newer fedoras and we always told no. When come speech about do 
  it
  on your own suddenly many questions marks raised up.
 
  The last open bug is: https://bugzilla.redhat.com/show_bug.cgi?id=1190137
  the guy is willing to maintain it.
 
  Fine, so let him do it and drop the Obsoletes: tag in java-1.8.0-openjdk
  and its successors. You shouldn't arbitrarily block people from
  re-introducing an older branch of any package back into Fedora in the
  first place.
 
 We can not do it. It will keep legacy jdks in users system. We don't wont  
 99% of users to keep 
 (unwillingly and unknowingly) old jdks. 99% of users is hepy with one - main 
 - jdk. To provide new 
 jdk , we have to obsolate old jdk...
 
 If you have workaround for this, please share. (Sewerin already higlighted it 
 on devel discussion).
 

I'm not an expert so probably I'm saying something wrong, but can't we
have -compact packages like we do with other libraries, and then handle
the compact libraries similarly to what the kernel does (that is, older
version are not wiped)?

Maybe I'm missing the obvious, but this seems to me like being drunk
while still having the barrel full :)

Cheers,
Mario

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Pete Travis

On Feb 24, 2015 8:32 AM, Mikolaj Izdebski mizde...@redhat.com wrote:

 On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
  I would much rather live without any legacy jdk, and if so then
without any
  rules. But not setting
  them will bring chaos for majority of users.
 
  I have a question: Is there anybody that stepped in to maintain the
legacy jdk?
  If there is nobody to maintain it trying to come up with this
guidelines now would be pointless.
  In short I think that such guidelines would better be created *only*
when there are interested parties, jointly with them and the process is
played a bit by some copr repo or similar. Purely theoretical work is not
needed.

 I fully agree with Alex here.

 I would add that if someone really wants to maintain older JDK in Fedora
 then it should up to *them* to come up with a solution that will work
 and satisfy expectations of JKD maintainers and Java SIG. Maintaining
 package is more than clicking unorphan in pkgdb.

 --
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 --


If some third party supplies 'java' as the $legacy jdk, and the user
installs a Fedora package built on $current jdk, which provider will win,
and what packages will break?

If the user uses alternatives to set the jdk (that applies here, right?)
any applications that need one version or the other could break?

I understand these are relatively ignorant questions, but if the aim is to
provide a path for someone to maintain older JDKs it seems better to offer
them guidelines and best practices instead of you'd better be competent
enough to figure it out.  They might not think of all the potential
conflicts.

--Pete
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 04:59 PM, Pete Travis wrote:
 On Feb 24, 2015 8:32 AM, Mikolaj Izdebski mizde...@redhat.com wrote:

 On 02/24/2015 02:17 PM, Aleksandar Kurtakov wrote:
 I would much rather live without any legacy jdk, and if so then
 without any
 rules. But not setting
 them will bring chaos for majority of users.

 I have a question: Is there anybody that stepped in to maintain the
 legacy jdk?
 If there is nobody to maintain it trying to come up with this
 guidelines now would be pointless.
 In short I think that such guidelines would better be created *only*
 when there are interested parties, jointly with them and the process is
 played a bit by some copr repo or similar. Purely theoretical work is not
 needed.

 I fully agree with Alex here.

 I would add that if someone really wants to maintain older JDK in Fedora
 then it should up to *them* to come up with a solution that will work
 and satisfy expectations of JKD maintainers and Java SIG. Maintaining
 package is more than clicking unorphan in pkgdb.

 --
 Mikolaj Izdebski
 Software Engineer, Red Hat
 IRC: mizdebsk
 --

 
 If some third party supplies 'java' as the $legacy jdk, and the user
 installs a Fedora package built on $current jdk, which provider will win,
 and what packages will break?

It's implementation detail of different package management systems
(yum/dnf etc) and in general it's unspecfied. My experience shows that
multiple packages providing the same thing are unreliable in practice
and best avoided.

 If the user uses alternatives to set the jdk (that applies here, right?)
 any applications that need one version or the other could break?

Particular applications can be configured to use different JRE/JDK
versions (for example you can run Maven with Java 8, but Ant with Java
7). Per-user configuration is also possible (user bob runs Maven with
Java 8, but fred with Java 7). Fedora is quite flexible in this aspect.

Moreover, Fedora can be configured not to use alternatives for Java
apps, so you can have /usr/bin/java pointing to old JDK while Fedora
applications are running with default (latest) JDK.

 I understand these are relatively ignorant questions, but if the aim is to
 provide a path for someone to maintain older JDKs it seems better to offer
 them guidelines and best practices instead of you'd better be competent
 enough to figure it out.  They might not think of all the potential
 conflicts.

If someone wants to maintain old JDK they are free to do so. Moreover,
they will surely get help from Java SIG with implementing that, provided
they show enough involvement. But IMO packaging guidelines is not a
place for listing details how compat packages for JDK should look like.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

On 02/24/2015 04:36 PM, Deepak Bhole wrote:
 * Mikolaj Izdebski mizde...@redhat.com [2015-02-24 10:12]:
 On 02/24/2015 04:06 PM, Deepak Bhole wrote:
 * Mikolaj Izdebski mizde...@redhat.com [2015-02-24 09:58]:
 On 02/24/2015 03:32 PM, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
 09:29]:
 On Tuesday, 24 February 2015 at 15:09, Deepak Bhole wrote:
 * Dominik 'Rathann' Mierzejewski domi...@greysector.net [2015-02-24 
 09:04]:
 On Tuesday, 24 February 2015 at 14:28, Jiri Vanek wrote:
 [...]
 There were several attempts in past like can you please support jdk
 7,6...in newer fedoras and we always told no. When come speech about 
 do it
 on your own suddenly many questions marks raised up.

 The last open bug is: 
 https://bugzilla.redhat.com/show_bug.cgi?id=1190137
 the guy is willing to maintain it.

 Fine, so let him do it and drop the Obsoletes: tag in 
 java-1.8.0-openjdk
 and its successors. You shouldn't arbitrarily block people from
 re-introducing an older branch of any package back into Fedora in the
 first place.


 We have no intention of blocking it. The reason for proposing these
 restrictions is that the Fedora Java stack will not work with older
 JDKs, therefore we need to make sure that it goes not get installed on
 the system unless explicitly requested by someone who knows what they
 are doing.

 Well, you do that by adding/updating (Build)Requires: in the packages
 which won't work otherwise, not by adding Obsoletes:.


 That would generally work for most packages, but there is a new JDK
 released every 2 years. This means that we would have to change the BR
 and Requires for the entire Java stack (100s and 100s of packages) every
 2 years, which is non-trivial.

 First, we have versioned auto-requires generated during package build.
 Explicit requires on java aren't usually needed. If package requires
 java  1:1.7 then it is correct - the package can be assumed to work
 with older JDK.


 While that is true in terms of source compatibility, it will work only
 if it is compiled with the older JDK.

 Secondly, it is fairly easy to add requires on java-devel = 1:1.8 to
 packages related to build systems like ant, maven or gradle. This would
 cover most cases of building Java packages using latest JDK.


 As you stated, it will cover most cases, but not all. More critically,
 this does not solve the issue with requirement of 'java' itself.

 These few remaining cases can be easily handled by provenpackager as
 mass-change.

 Also, my proposal of introducing java metapackage (see my other post
 in this thread), which would always require the latest JDK, solves this
 problem in a different way, without modifying ordinary Java packages at all.

 
 Ah, I had missed that. Yes, the metapackage solution should work to the
 same effect. I don't know if we can just call it 'java' though, unless
 you are proposing that 'java' provision be removed from current openjdk
 packages?

I'm not really proposing as I haven't thought about this much yet, but
the idea was about be adding a few empty binary packages java,
java-devel, java-headless and so on (they could be subpackages of
javapackages-tools). Existing provides with the same names could be
removed from JDK packages.

java would be the preferred JRE in Fedora. The package would have no
content, but it would have Requires on preferred Fedora JRE, currently
java-1.8.0-openjdk. This could be easily changed as default JRE changes.
The same is for other binary subpackages of java, respectively.

All system packages would require subpackages of java as they do now
(unless there is good reason not to). Users that install java would
get latest JRE, which would be updated to new major versions as they
become default. Older JDKs would not be removed during update (unless
there is no maintainer and they are obsoleted as currently), but users
could remove them with yum autoremove, unless something requires older
JDK or they installed it explicitly.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Mario Torre

On Tue, 2015-02-24 at 15:37 +0100, Mikolaj Izdebski wrote:
 On 02/24/2015 02:15 PM, Jiri Vanek wrote:
  On 02/24/2015 12:43 PM, Mikolaj Izdebski wrote:
  I am against official guidelines or policy for legacy JDK packages. I
  don't think that any such policy is needed and it would only encourage
  adoption of old packages for which there might be no security updates.
  
  Well thats the point - people are calling for them. And wont to maintain
  them with this risk.
 
 I thought that the point of this change proposal was enabling community
 to maintain legacy JDKs, not encouraging people to package them without
 good reason or without involvement to truly maintaining them. Packaging
 older JDKs is *already* possible, so IMHO this change accomplishes
 nothing but showing people how they can dump old, unmaintained software
 into Fedora.

Well, in this case it would not be un-maintained, the Fedora package
would *not* be maintained *by us* (the Red Hat Java Team) indeed, but we
are still actively contributing to the upstream software in its various
versions. While you as a packager cannot specifically count on that,
there's still a level of confidence that the base software won't be
abandoned any time soon. And even when we will stop supporting those
older versions, the community will take over if there is a need for
that, exactly like we have done ourselves before.

Indeed, there's an overhead for the downstream maintainers, we may need
to drop specific version of OpenJDK, or skip a release, or do other
funny things and the Fedora maintainers will have to adapt, but this is
no different than usual I believe. Realistically, we are so conservative
with older JDKs that I doubt this will ever really be an issue.

  Currently anyone is allowed to maintain legacy JDKs in Fedora according
  to general rules, so this change proposal does not enable maintenance
  of legacy JDKs.
  
  It is not true. We were killing old packages withut handling the
  owenership or maintainerships to others.
 
 Why this is not true? What prevents me from reviving java-1.6.0-openjdk
 or java-1.7.0-openjdk in Fedora and making it available in rawhide? If I
 wanted could just follow standard process and bring it back any time.

You may be able to do that, but you should be careful to not break
existing functionality or you're attract the wrath of your own users!

Changes should be carefully pondered, so defining a process for such
thing to go smooth is not a bad thing.

  === Proposed rules ===
  0. '''Main JDK maintainers are not never ever responsible for any
  legacy jdk.
  This must remain clear'''
 
  Package maintainers are responsible for their packages. If maintainer of
  main JDK is also maintaining legacy JDK then (s)he should be
  responsible for both of them. I don't see why any special rule should be
  defined.
  
  As I higlighted - we - main jdk team - are never ever going to do so.
 
 Imagine that someone become comaintainer of main JDK. This rule would
 prevent him from maintaining (and being responsible) for older JDK.
 This limits people's freedom and that's why I am against that.

I really fail to see in what way this is limiting people freedom to do
anything, a process is just a way to organise work, is a mean, not the
end goal in itself, and to what I'm able to judge the proposed process
makes mostly sense.

  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 overorpahned 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)
 
  Currently all compat packages must complete full review before being
  introduced. Why JDK should be treated specially? I think that with
  complex system of virtual provides, alternatives and strict directory
  layout it's necessary to fully review legacy JDK package to make sure
  it doesn't conflict with primary JDK and that it is integrated with
  Fedora as expected.
  
  Well the jdk - as is now - will never pass regular review - it is
  handling config files and libraries and shared jars really differently -
  and have good purposes for it.
 
 Package that doesn't pass review shouldn't be part of Fedora.

Well, if your goal is to reduce the user base of Fedora, I'm sure we can
talk about removing the JDK :)

Cheers,
Mario


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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

2015-02-24 Thread Miloslav Trmač

Hello,
 java would be the preferred JRE in Fedora. The package would have no
 content, but it would have Requires on preferred Fedora JRE, currently
 java-1.8.0-openjdk. This could be easily changed as default JRE changes.
 The same is for other binary subpackages of java, respectively.
 
 All system packages would require subpackages of java as they do now
 (unless there is good reason not to). Users that install java would
 get latest JRE, which would be updated to new major versions as they
 become default. Older JDKs would not be removed during update (unless
 there is no maintainer and they are obsoleted as currently),

AFAIK nothing obsoletes a package just because it is orphaned…
 but users
 could remove them with yum autoremove, unless something requires older
 JDK or they installed it explicitly.
… but most won’t run (yum autoremove).  In effect, the vast majority of users 
upgrading from a previous Fedora version would end up with two JDKs installed, 
one of them an old, unmaintained RPM.
Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

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