Bug 1190137 - Cannot install java-1.7.0-openjdk on a system with java-1.8.0-openjdk using yum
Summary: Cannot install java-1.7.0-openjdk on a system with java-1.8.0-openjdk using yum
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk
Version: 21
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: jiri vanek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-02-06 12:30 UTC by Julius Schwartzenberg
Modified: 2017-08-18 20:45 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-03-23 10:20:34 UTC
Type: Bug


Attachments (Terms of Use)
patch for centos spec file (3.52 KB, patch)
2015-03-06 12:40 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for centos spec file v2 (3.77 KB, patch)
2015-03-06 16:51 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for centos spec file v3 (3.84 KB, patch)
2015-03-13 15:32 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for centos spec file v4 (4.38 KB, patch)
2015-03-17 17:10 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for centos spec file v5 (4.38 KB, patch)
2015-03-30 16:00 UTC, Julius Schwartzenberg
no flags Details | Diff
OpenJDK 1.6 patch for centos spec file (3.39 KB, patch)
2015-03-30 16:00 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.7.0 u95 spec file (4.50 KB, patch)
2016-01-25 17:02 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.6.0 u38 (5.90 KB, patch)
2016-02-05 15:36 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.7.0 u95 spec file for Fedora 23 (5.31 KB, patch)
2016-02-05 15:36 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.6.0 u39 (Fedora 23) (5.93 KB, patch)
2016-05-10 14:06 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.7.0 u101 (Fedora 23) (5.35 KB, patch)
2016-05-10 16:07 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.6.0 u39 (Fedora 24) (8.35 KB, patch)
2016-06-24 12:34 UTC, Julius Schwartzenberg
no flags Details | Diff
patch backported from 1.8 to solve GCC 6 compile issues (10.68 KB, patch)
2016-06-24 12:34 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.7.0 u101 (Fedora 24) (7.13 KB, patch)
2016-06-24 12:35 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.6.0 u40 (Fedora 24) (8.05 KB, patch)
2016-09-09 15:36 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.6.0 u40 1.13.12.9 (Fedora 24) (8.02 KB, patch)
2016-11-09 13:55 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.7.0 u121 (Fedora 24) (7.14 KB, patch)
2016-11-09 13:55 UTC, Julius Schwartzenberg
no flags Details | Diff
patch for OpenJDK 1.6.0 u41 (Fedora 25) (6.90 KB, patch)
2017-02-14 16:05 UTC, Julius Schwartzenberg
no flags Details | Diff

Description Julius Schwartzenberg 2015-02-06 12:30:53 UTC
Description of problem:
For development I need multiple OpenJDK versions installed (1.6, 1.7 & 1.8). When I try to install OpenJDK 1.7 from my repository, it refuses to install because OpenJDK 1.8 is already installed

Version-Release number of selected component (if applicable):
1.8.0.31-3.b13.fc21.x86_64

How reproducible:

Steps to Reproduce:
1. Install Fedora 21 with OpenJDK 1.8
2. Build OpenJDK 1.7 for Fedora (rpmbuild --rebuild on the CentOS 7 src package works fine) and put it in a yum repository
3. Add this yum repository to the Fedora 21 (with obsoletes=0)
4. Changes obsoletes=1 to obsoletes=0 in /etc/yum.conf
5. 'yum install java-1.7.0-openjdk-devel'

Actual results:
It won't install:
[root@localhost ~]# yum install java-1.7.0-openjdk-devel
Repository 'abz-extras' is missing name in configuration, using id
Resolving Dependencies
--> Running transaction check
---> Package java-1.7.0-openjdk-devel.x86_64 1:1.7.0.75-2.5.4.2.fc21 will be installed
--> Processing Dependency: java-1.7.0-openjdk = 1:1.7.0.75-2.5.4.2.fc21 for package: 1:java-1.7.0-openjdk-devel-1.7.0.75-2.5.4.2.fc21.x86_64
--> Running transaction check
---> Package java-1.7.0-openjdk.x86_64 1:1.7.0.75-2.5.4.2.fc21 will be installed
--> Processing Dependency: java-1.7.0-openjdk-headless = 1:1.7.0.75-2.5.4.2.fc21 for package: 1:java-1.7.0-openjdk-1.7.0.75-2.5.4.2.fc21.x86_64
--> Running transaction check
---> Package java-1.7.0-openjdk-headless.x86_64 1:1.7.0.75-2.5.4.2.fc21 will be installed
Removing java-1.7.0-openjdk.x86_64 1:1.7.0.75-2.5.4.2.fc21 - u due to obsoletes from installed 1:java-1.8.0-openjdk-1.8.0.31-3.b13.fc21.x86_64
Removing java-1.7.0-openjdk-devel.x86_64 1:1.7.0.75-2.5.4.2.fc21 - u due to obsoletes from installed 1:java-1.8.0-openjdk-devel-1.8.0.31-3.b13.fc21.x86_64
Removing java-1.7.0-openjdk-headless.x86_64 1:1.7.0.75-2.5.4.2.fc21 - u due to obsoletes from installed 1:java-1.8.0-openjdk-headless-1.8.0.31-3.b13.fc21.x86_64
--> Restarting Dependency Resolution with new changes.
--> Running transaction check
---> Package java-1.7.0-openjdk.x86_64 1:1.7.0.75-2.5.4.2.fc21 will be installed
---> Package java-1.7.0-openjdk-devel.x86_64 1:1.7.0.75-2.5.4.2.fc21 will be installed
---> Package java-1.7.0-openjdk-headless.x86_64 1:1.7.0.75-2.5.4.2.fc21 will be installed
--> Finished Dependency Resolution

Expected results:
I expect OpenJDK 1.8 to upgrade OpenJDK 1.7 for end users, but for developers an option to allow installation of OpenJDK 1.7 through yum. I have all forms of obsolete checking disabled.

There is an option in yum to downgrade packages when only the version number has changed. This does not apply at all to packages which are obsoleted by packages that have a new name.

Comment 1 jiri vanek 2015-02-06 12:45:47 UTC
Hello.

Unluckily this is intentional. In fedora 21+ is no openjdk7. So during update, your jdk7 was replaced  by jdk8

There was long thread about this on devel list, with no clear result.
Issue is, that java maintainers do not have enough man power to maintain more then one jdk in fedora. The 8 is main jdk now. From time to time we push also techpreview jdk ito fedora - as we did in f20 and f19 with jdk8. 

This is currently closed not a bug. The only solution is, that somebody will be willing to take ownership of jdk7 onto himself. Are you wiling?

If so, you may start to take care for jdk7 for f21/rawhide. The only necessary thing is to be sure that it not appear in buildroot. For example by removing provides java/java-devel and similar.

Comment 2 Julius Schwartzenberg 2015-02-06 13:14:27 UTC
(In reply to jiri vanek from comment #1)
> Unluckily this is intentional. In fedora 21+ is no openjdk7. So during
> update, your jdk7 was replaced  by jdk8

The problem is not the availability of the package. I took the source RPMs from CentOS 7 and managed to build them on Fedora 21 without any changes. It's these packages that I have in my local yum repository.

The problem is that these packages are not installable through yum, because of its strict obsolete handling. It appears there is no way to avoid this now.

I wouldn't mind maintaining jdk6 and jdk7 for Fedora. RedHat will provide updates for CentOS 7 for a long time and those sources compile perfectly fine on Fedora 21. I don't think that would solve this issue directly however.

Comment 3 Deepak Bhole 2015-02-06 14:17:26 UTC
Another main issue with adding OpenJDK < 8 in Fedora will be that it will be incompatible with all other Java packages in the stack. All packages are presently built with OpenJDK8 and the class file format is not backwards compatible with OpenJDK7. In CentOS7 this is not an issue because OpenJDK7 is the base JDK there.

Comment 4 Julius Schwartzenberg 2015-02-06 14:40:40 UTC
(In reply to Deepak Bhole from comment #3)
> Another main issue with adding OpenJDK < 8 in Fedora will be that it will be
> incompatible with all other Java packages in the stack. All packages are
> presently built with OpenJDK8 and the class file format is not backwards
> compatible with OpenJDK7. In CentOS7 this is not an issue because OpenJDK7
> is the base JDK there.

There's no reason to change the base JDK. I keep OpenJDK8 as the base JDK in Fedora 21. OpenJDK7 and OpenJDK6 are installed in addition and can be used to build applications for older application servers while all the included tools such as Maven, Eclipse, etc. run in OpenJDK8.

Comment 5 Andrew John Hughes 2015-02-06 16:21:40 UTC
Why not just use CentOS or RHEL? That would seem like the simpler solution, rather than maintaining your own Fedora packages for 6 & 7.

Comment 6 Deepak Bhole 2015-02-06 16:45:11 UTC
(In reply to Julius Schwartzenberg from comment #4)
> (In reply to Deepak Bhole from comment #3)
> > Another main issue with adding OpenJDK < 8 in Fedora will be that it will be
> > incompatible with all other Java packages in the stack. All packages are
> > presently built with OpenJDK8 and the class file format is not backwards
> > compatible with OpenJDK7. In CentOS7 this is not an issue because OpenJDK7
> > is the base JDK there.
> 
> There's no reason to change the base JDK. I keep OpenJDK8 as the base JDK in
> Fedora 21. OpenJDK7 and OpenJDK6 are installed in addition and can be used
> to build applications for older application servers while all the included
> tools such as Maven, Eclipse, etc. run in OpenJDK8.

Is it not possible to use '-source 7 -target 7' for this? Furthermore, what would such builds be targeting? They will still not work on Fedora unless they are fully self-contained. If the target is not Fedora, then building on CentOS as Andrew mentioned in comment #5 might be easier..

Comment 7 Julius Schwartzenberg 2015-02-06 20:17:08 UTC
(In reply to Andrew John Hughes from comment #5)
> Why not just use CentOS or RHEL? That would seem like the simpler solution,
> rather than maintaining your own Fedora packages for 6 & 7.

The Eclipse environment which is shipped with Fedora is much more extensive than the Eclipse environment from CentOS/RHEL or its developers toolset.

Running Fedora's Eclipse (on OpenJDK 1.8), it is possible to add OpenJDK 1.6 and OpenJDK 1.7 in it and run software, unit tests, etc. directly these JDKs. (It's also possible to install and add Oracle's JDKs as well for instance.)


(In reply to Deepak Bhole from comment #6)
> Is it not possible to use '-source 7 -target 7' for this? Furthermore, what
> would such builds be targeting? They will still not work on Fedora unless
> they are fully self-contained. If the target is not Fedora, then building on
> CentOS as Andrew mentioned in comment #5 might be easier..

That could potentially allow things to work, but it is usual to build, run tests, the software itself against the same JDK which is used on the production system. There have been significant differences between JDKs, so it is always preferable to stay as close to the production version as possible. The final build itself is done on CentOS, but development is easier on Fedora (some even do this on MS Windows with MS Windows versions of the same JDKs).

Comment 8 jiri vanek 2015-02-09 09:30:41 UTC
As we were used to use obsolete always, when main jdk was changed in fedora, this example is crossing the intention to orpahne 8 only. So actually fixing this bug prepare us to this way.

if jdk8 would not obsolete jdk7, but jdk7 will provide java7* stuff, and jdk8 priority will be higher, then  the result for basic user will be same:
 - he will have jdk8 as mian jdk
 - it will be installed and set  during update

 - side effect is, that jdk7 will remain installed too.

Obviously, removing the obsolete later in lifecycle is not an best option....

Comment 9 Deepak Bhole 2015-02-09 15:42:20 UTC
(In reply to jiri vanek from comment #8)
> As we were used to use obsolete always, when main jdk was changed in fedora,
> this example is crossing the intention to orpahne 8 only. So actually fixing
> this bug prepare us to this way.
> 
> if jdk8 would not obsolete jdk7, but jdk7 will provide java7* stuff, and
> jdk8 priority will be higher, then  the result for basic user will be same:
>  - he will have jdk8 as mian jdk
>  - it will be installed and set  during update
> 
>  - side effect is, that jdk7 will remain installed too.
> 
> Obviously, removing the obsolete later in lifecycle is not an best option....

Hi Jiri,

So to clarify, you are okay with removing the Obsoletes directive if OpenJDK < 8 provides only javaX where X is the version?

Comment 10 jiri vanek 2015-02-13 14:10:05 UTC
I have no better (aka not similar) idea  how to allow legacy jdks alive in Fedora. 

I'm maybe for more removal of all possible provides  instated of %{name} ) rather then adding X ones. Even if it is wrong, it is more symple to add them later then remove them later.

But to clarify  - Me (we) are not going to maintain those packages. Volunteers have to.

Comment 11 jiri vanek 2015-02-13 14:10:41 UTC
Imho  this will need Fesco involvement...

Comment 12 jiri vanek 2015-02-20 12:28:45 UTC
Hi again!

I'm trying to prepare some policy for f22  how to support legacy jdkS in fedora.

From curiosity, how evil will you consider, if you will be recommended (read "must" to rename the packages? eg to java-1.7.0-openjdk{,-devel,-javadoc,...}-legacy ?

Comment 13 Dominik 'Rathann' Mierzejewski 2015-02-24 14:00:42 UTC
No need for a new policy. Just drop the Obsoletes: java-1.7.0-openjdk from java-1.8.0-openjdk.spec.

Comment 14 jiri vanek 2015-02-24 14:05:33 UTC
(In reply to Dominik 'Rathann' Mierzejewski from comment #13)
> No need for a new policy. Just drop the Obsoletes: java-1.7.0-openjdk from
> java-1.8.0-openjdk.spec.

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

Also please continue discussion about htose polycies rather on devel list, then here.

Comment 15 jiri vanek 2015-02-24 14:06:07 UTC
For a sake of information - https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora - is What Dominik was mentioning as "polycies"

Comment 16 jiri vanek 2015-02-27 13:32:57 UTC
Hello again!

If you really wont to maintain legacy JDK in fedora, you can.
https://fedoraproject.org/wiki/Changes/LegacyJDKsInFedora.

I would strongly encourage youto go with: https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred

During your work the rules will evolve.

If you do not wont to maintainit, I will close this as "closed wontfix"

Comment 17 Julius Schwartzenberg 2015-03-02 12:24:58 UTC
(In reply to jiri vanek from comment #16)
> I would strongly encourage youto go with:
> https://fedoraproject.org/wiki/User:Jvanek/Changes/
> LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred

I think I should try option 3 first and if that works out, migrate to option 1. I'll try to find time to look into this. Thanks for your help, it will be a good guide for me!

Comment 18 jiri vanek 2015-03-02 13:27:36 UTC
Ok. Still - even in coper repo - I would encourage you to go with -legacy suffix. Because otherwise the yum will prevent you to install it, because of openjdk8 still obsolate java-1.7.0-openjdk.

Comment 19 Julius Schwartzenberg 2015-03-06 12:40:05 UTC
Created attachment 998783 [details]
patch for centos spec file

I created a patch based on the spec file I got from the CentOS 7 source RPM to implement option 1. It would seem the easiest way to maintain this, but I don't really know what is the normal policy. What do you think of this?

One question I have regarding point 3, the priority among the alternatives. What is the reason that the number of digits should be 5? Wouldn't a six-digit priority starting with 18 always win over a six-digit priority starting with 17? In the current patch I do reduce the number of digits to 5, but I think this change is not really necessary.

Comment 20 jiri vanek 2015-03-06 13:40:30 UTC
Hi!

The rule 3 - simply lowering the priority is not enough. You need to include also this 4 lines : http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/tree/java-1.8.0-openjdk.spec?id=fb001ce997e7fc95c1eeca02d3ed004dc59035a1#n956
from this patch: http://pkgs.fedoraproject.org/cgit/java-1.8.0-openjdk.git/commit/?id=fb001ce997e7fc95c1eeca02d3ed004dc59035a1

With one necessary change - to make this to die on  size of 5.


The reason why I'm "forcing" you to reduce to 5 (or less) is this - 
By some accident, you may  increase the priority to 8 or more digits. It is improbable, but may happen. And suddenly 17000000 > 180000. So thats why it is needed here. I'mnot forcing you to downgrade to less digits then 5, because I would like to keep you as much fredom as play with priority as possible.

Patch itself:
Except missing priority checks , I can see:
- Patch106: %{name}-freetype-check-fix.patch
+ Patch106: java-%{javaver}-%{origin}-freetype-check-fix.patch

I would recommend you to include global of origname java-%{javaver}-%{origin} and use this origname in places where name needs update. 

The rest of the patch are removed provides. You really have to remove *all* virtual provides, unless it will kill your usecase. If it will kill your usecase, then there are two options:

If you will be runing copr repo - then you actually can keep them all in, as no uninterested user will be affected by acidence, nor build root and so on..

If you are going to include them in regular fedora, I'm afraid all of them really have to be removed - or theirs existence must be heavily discussed.


Next - if you are doing copr repo, then there are no official rules I'm aware about. 

If you wont to include this java-1.7.0-openjdk-legacy in fedora then you need to pass regular review process - https://fedoraproject.org/wiki/Join_the_package_collection_maintainers -  Here I will be your's reviewer probably and we may try to push it in.

Comment 21 Julius Schwartzenberg 2015-03-06 14:51:53 UTC
Thanks for your quick response. I'll create a new version of the patch with your feedback.

About the provides however. I think that all provides which include %{javaver} in the package name part can stay. They should never overlap in any way with anything from a newer version, but they would enable packages which would depend on a specific JDK version to continue to work. All provides which do not include %{javaver} should be removed by the patch.

Comment 22 Julius Schwartzenberg 2015-03-06 16:51:31 UTC
Created attachment 998940 [details]
patch for centos spec file v2

Here's the revised version of the patch.

Comment 23 Julius Schwartzenberg 2015-03-13 15:32:52 UTC
Created attachment 1001431 [details]
patch for centos spec file v3

Here's another version. I've added a provide to provide the original java-1.7.0-openjdk-devel package. This seems the most appropriate way to solve the build dependency and allow packages still depending on specifically this JDK version to build.

Comment 24 Julius Schwartzenberg 2015-03-13 15:39:54 UTC
I've tried to set up a copr repository, but my build fails in a way I do not understand. Here are the logs:
https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-21-x86_64/java-1.7.0-openjdk-legacy-1.7.0.75-2.5.4.2.fc21/

Locally I do not have any problems with building. I've published these builds in a yum repo here (also to bootstrap the copr build):

http://schwart6.home.xs4all.nl/fedora21/binaries/

Janek, you think I should look into fixing the issue with copr first or try the Fedora review process already? What do you think of my current patch?

When I've got OpenJDK 1.7 up properly, I can arrange the same for OpenJDK 1.6. I expect it will be almost the same patch.

Comment 25 Omair Majid 2015-03-13 15:50:39 UTC
(In reply to Julius Schwartzenberg from comment #24)
> I've tried to set up a copr repository, but my build fails in a way I do not
> understand.

It's bug 1194817.

Comment 26 jiri vanek 2015-03-16 13:15:15 UTC
(In reply to Julius Schwartzenberg from comment #24)
> I've tried to set up a copr repository, but my build fails in a way I do not
> understand. Here are the logs:
> https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-21-
> x86_64/java-1.7.0-openjdk-legacy-1.7.0.75-2.5.4.2.fc21/
> 
> Locally I do not have any problems with building. I've published these
> builds in a yum repo here (also to bootstrap the copr build):
> 
> http://schwart6.home.xs4all.nl/fedora21/binaries/
> 

Awesome!

> Janek, you think I should look into fixing the issue with copr first or try

According to  bugid Omair posted, the issue in coper have been already resolved.

> the Fedora review process already? What do you think of my current patch?

Looks good, except the provides:) Why you are keeping few of them inside?
If you wont to go with fedora review process, I would really like you to  remove *all* virtual provides, *unless* it kills yours  usecase.

So why you are keeping them in? Have it already caused any troubles?

Don't forget, that package always provides NAME = VR.
In your case individual rpms provides:
 java-1.7.0-openjdk-legacy = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-accessibility = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-debuginfo = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-demo = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-devel = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-headless = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-javadoc = 1.7.0.75-2.5.4.2.fc21
 java-1.7.0-openjdk-legacy-src = 1.7.0.75-2.5.4.2.fc21

So basically you do not need any virtual provides. If you need any (build)requirement, you would use for java
Reuires: java-1.7.0-openjdk-legacy
or for javac eg:
BuildReuires: java-1.7.0-openjdk-legacy-devel

Isn't it enough?


I have tested your packages a bit, and they are working great!
> 
> When I've got OpenJDK 1.7 up properly, I can arrange the same for OpenJDK
> 1.6. I expect it will be almost the same patch.

Its completely up to you:).  But I agree that waiting until jdk7 is in or "in coper"  is definitely good idea.

Also I'm impressed by small necessary patch.  Thats making me believe that https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred is really best way to go.

Thank you your efforts. I'm hoping to see those in fedora soon!

Comment 27 Julius Schwartzenberg 2015-03-16 17:07:17 UTC
(In reply to jiri vanek from comment #26)
> (In reply to Julius Schwartzenberg from comment #24)
> > Janek, you think I should look into fixing the issue with copr first or try
> 
> According to  bugid Omair posted, the issue in coper have been already
> resolved.

I just restarted the build there, let's see whether it'll finish now.


> > the Fedora review process already? What do you think of my current patch?
> 
> Looks good, except the provides:) Why you are keeping few of them inside?
> If you wont to go with fedora review process, I would really like you to 
> remove *all* virtual provides, *unless* it kills yours  usecase.
> 
> So why you are keeping them in? Have it already caused any troubles?

I would say that the provides which include a version number would never cause problems. At the same time keeping them increases compatibility with existing packages and compatibility with the RHEL/CentOS packages.
Are there any disadvantages in keeping them?


> Don't forget, that package always provides NAME = VR.
> In your case individual rpms provides:
>  java-1.7.0-openjdk-legacy = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-accessibility = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-debuginfo = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-demo = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-devel = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-headless = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-javadoc = 1.7.0.75-2.5.4.2.fc21
>  java-1.7.0-openjdk-legacy-src = 1.7.0.75-2.5.4.2.fc21
> 
> So basically you do not need any virtual provides. If you need any
> (build)requirement, you would use for java
> Reuires: java-1.7.0-openjdk-legacy
> or for javac eg:
> BuildReuires: java-1.7.0-openjdk-legacy-devel
> 
> Isn't it enough?

Yes, for my usecase this would be enough.


> Also I'm impressed by small necessary patch.  Thats making me believe that
> https://fedoraproject.org/wiki/User:Jvanek/Changes/
> LegacyJDKsInFedora#option_one_-_introducing_new_packages_-_preferred is
> really best way to go.

I think it shows how great the (source) compatibility is between RHEL/CentOS & Fedora.


> Thank you your efforts. I'm hoping to see those in fedora soon!

Thank you for all the support with this. I'll do my best to get this in!

Comment 28 jiri vanek 2015-03-17 09:07:42 UTC
> > So why you are keeping them in? Have it already caused any troubles?
> 
> I would say that the provides which include a version number would never
> cause problems.

Hmhmhmh, maybe you are right and I'm just to much paranoid

> At the same time keeping them increases compatibility with
> existing packages and compatibility with the RHEL/CentOS packages.

I would like to avoid *legacy packages being used as dependency in any regular fedora package. This is a bit prevention. 

> Are there any disadvantages in keeping them?

Yes. I would like to avoid any possible by-accident usage.  

Consider this scenario:

I have package, and I had brroken rules, and I'm requiring
java-1.8.0-openjdk-headless instead of java
JDK8 will eoled, I do not notice.
Somebody pickup jdk8 and will create java-1.8.0-openjdk-legacy
But because of it still provides java-1.8.0-openjdk then my pacage will suddenly being dependent on obsoilated jdk, instead on main fedora jdk.

Then it may be also pulled to unaware user's system, 
> 
> 
> > Don't forget, that package always provides NAME = VR.
> > In your case individual rpms provides:
> >  java-1.7.0-openjdk-legacy = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-accessibility = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-debuginfo = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-demo = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-devel = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-headless = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-javadoc = 1.7.0.75-2.5.4.2.fc21
> >  java-1.7.0-openjdk-legacy-src = 1.7.0.75-2.5.4.2.fc21
> > 
> > So basically you do not need any virtual provides. If you need any
> > (build)requirement, you would use for java
> > Reuires: java-1.7.0-openjdk-legacy
> > or for javac eg:
> > BuildReuires: java-1.7.0-openjdk-legacy-devel
> > 
> > Isn't it enough?
> 
> Yes, for my usecase this would be enough.
> 
> 

Then I'm +1 to  remove all virtual provides. Maybe  add them back in live time.

Comment 29 Julius Schwartzenberg 2015-03-17 17:10:07 UTC
Created attachment 1002881 [details]
patch for centos spec file v4

(In reply to jiri vanek from comment #28)
> Then I'm +1 to  remove all virtual provides. Maybe  add them back in live
> time.

Here's a new patch that does this. I indeed suppose we can always add back these provides when it turns out that we need compatibility with existing packages which depend on specific JDK versions.

The build with this is also available here:
https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/

Let me know when/what should be the next step to get this further!

Comment 30 jiri vanek 2015-03-20 16:27:49 UTC
I'm ok with this approach. Now depends on you if you wants to keep them in kopr or do an reiw request.  If the first, you are done. If the second then do an review request. I will be happy to be an reviwer for this (please let me know once it is posted on review - via this bug or by email - and I will take it)
Also note - during the formal review, this effort may be suspended form fedora-devel. We did not completely agreed on some rules, and actually it was 50/50 nearly on each.

So you will need to be patient with us.

https://fedoraproject.org/wiki/Join_the_package_collection_maintainers
http://fedoraproject.org/wiki/Package_Review_Process

As resutl of the https://fedoraproject.org/wiki/User:Jvanek/Changes/LegacyJDKsInFedora and of this official review some modifications to current pacakging guidelines or to your current patch may evolve

Comment 31 Julius Schwartzenberg 2015-03-20 17:13:19 UTC
Ah yes, I had missed this discussion. For now I will put both OpenJDK 1.6 and 1.7 with your guidelines in COPR then, which will enable installation without any obsolete-issues.

My intention for this bug report originally wasn't to get the old JDKs in Fedora itself, just a way to get around yum's obsolete checking. It was easy to build Fedora packages from the CentOS sources. I just needed a way around yum removing them for supposedly being obsolete.

Comment 32 jiri vanek 2015-03-23 10:20:34 UTC
(In reply to Julius Schwartzenberg from comment #31)
> Ah yes, I had missed this discussion. For now I will put both OpenJDK 1.6

You did not miss to much, there was a lot of loud, but not much results

> and 1.7 with your guidelines in COPR then, which will enable installation
> without any obsolete-issues.

oook:( As you feel right!-)
If you ever wont those in main repo, feel free to let me know.
> 
> My intention for this bug report originally wasn't to get the old JDKs in
> Fedora itself, just a way to get around yum's obsolete checking. It was easy
> to build Fedora packages from the CentOS sources. I just needed a way around
> yum removing them for supposedly being obsolete.


Then I will close this bug.

Comment 33 Julius Schwartzenberg 2015-03-30 16:00:17 UTC
Created attachment 1008578 [details]
patch for centos spec file v5

Bugfix for OpenJDK 1.7 patch.

Comment 34 Julius Schwartzenberg 2015-03-30 16:00:57 UTC
Created attachment 1008580 [details]
OpenJDK 1.6 patch for centos spec file

Comment 35 Julius Schwartzenberg 2015-03-30 16:06:10 UTC
I've packaged both OpenJDK 1.6 and OpenJDK 1.7 for Fedora 21 now. The patches are attached here. The Copr repositories are here:
https://copr.fedoraproject.org/coprs/jschwart/openjdk-6/
https://copr.fedoraproject.org/coprs/jschwart/openjdk-7/

I guess this would help most developers that need the older OpenJDKs in Fedora. If anyone would like this to be pushed into Fedora officially, I'm open to cooperate more on this.

If anyone finds problems with these builds, please let me know!

Comment 36 jiri vanek 2015-04-30 12:26:06 UTC
So it happened in time, that I become yours regural user. Ty for maintain those!

J.

Comment 37 Julius Schwartzenberg 2015-05-03 17:09:43 UTC
Glad to hear this! I just noticed my OpenJDKs on CentOS got upgraded and pushed the same updates to the respective COPRs. I didn't do much more than applying the patches from here and pushing it to COPR, so please let me know if there are any issues!

Comment 38 jrior001 2015-06-04 14:00:51 UTC
Any chance we can get a fedora22 builds up as well?

Comment 39 Julius Schwartzenberg 2015-06-10 15:41:09 UTC
I haven't got a Fedora 22 system yet, but should have one soon to see what needs to be done for the build. I tried it now without any changes, but for some reason the build failed:
https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-22-x86_64/java-1.7.0-openjdk-legacy-1.7.0.79-2.5.5.1.fc21/

Maybe the Fedora 21 builds will install/work on Fedora 22 for now?

Comment 40 jiri vanek 2015-06-10 15:52:26 UTC
They seems to be working. The build issue should be fixable by:
http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2015-June/032239.html

Comment 41 Omair Majid 2015-06-10 15:58:52 UTC
(In reply to Julius Schwartzenberg from comment #39)
> I haven't got a Fedora 22 system yet, but should have one soon to see what
> needs to be done for the build. I tried it now without any changes, but for
> some reason the build failed:
> https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-22-
> x86_64/java-1.7.0-openjdk-legacy-1.7.0.79-2.5.5.1.fc21/

On Fedora 22, you may also need the following patch:
http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/629f25b8fc9d

Comment 42 Julius Schwartzenberg 2015-11-24 14:11:42 UTC
I'm looking at deploying the new versions on Fedora 21 but it seems updates to Fedora 21 introduced a problem with systemtap. When I compile a build of OpenJDK 1.6 which worked before (locally), I now get this error:
checking working sys/sdt.h and g++ support... configure: error: systemtap sdt.h or g++ too old

I tried downgrading systemtap (from 2.9 to 2.6) but that does not solve the problem. Does anyone happen to know what's going on here?

I hope the Fedora 21 binaries run on 22 and 23, I still haven't found time to get these installations up and running to provide specific packages for them.

Comment 43 Andrew John Hughes 2015-11-26 19:58:49 UTC
(In reply to Omair Majid from comment #41)
> (In reply to Julius Schwartzenberg from comment #39)
> > I haven't got a Fedora 22 system yet, but should have one soon to see what
> > needs to be done for the build. I tried it now without any changes, but for
> > some reason the build failed:
> > https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-22-
> > x86_64/java-1.7.0-openjdk-legacy-1.7.0.79-2.5.5.1.fc21/
> 
> On Fedora 22, you may also need the following patch:
> http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/629f25b8fc9d

That's part of 2.5.6 and 2.6.0. See PR2326 in IcedTea Bugzilla.

Comment 44 Julius Schwartzenberg 2016-01-25 17:02:47 UTC
Created attachment 1118125 [details]
patch for OpenJDK 1.7.0 u95 spec file

I just uploaded the latest versions for Fedora 22. It appears all the required patches are included in the CentOS/RHEL packages now. I hope to move to Fedora 23 as well, but it appears that builds for previous versions should run on newer versions in general.

If anybody needs any extra architectures checked, let me know and I'll run builds for them as well.

Comment 45 Julius Schwartzenberg 2016-01-29 15:57:19 UTC
Testing building on Fedora 23 reveals that at-spi-devel is removed which contained a libspi-1.0 package config needed to do a plain build.

I do not immediately know what would be the best solution for this. The last OpenJDK 1.7 in Fedora (20) also still had this dependency. Are there any known tweaks already to let it work with the newer version 2 of the library which is included?

A possible solution could be to provide the old at-spi packages through COPR as well.

Comment 46 Omair Majid 2016-01-29 16:16:55 UTC
(In reply to Julius Schwartzenberg from comment #45)
> Testing building on Fedora 23 reveals that at-spi-devel is removed which
> contained a libspi-1.0 package config needed to do a plain build.
> 
> I do not immediately know what would be the best solution for this. The last
> OpenJDK 1.7 in Fedora (20) also still had this dependency. Are there any
> known tweaks already to let it work with the newer version 2 of the library
> which is included?

If you could somehow get at-spi-devel to work, it's not really supported anymore by desktop environments, so it's not going to be very useful. 

OpenJDK 1.7 should Just Work with java-atk-wrapper (just like java-1.8.0-openjdk does). I think all you need to do is symlink the java-atk-wrapper jar, put the right bits in the accessibility properties and security properties file and you should be good to go.

For testing that it works for Swing applications, https://wiki.gnome.org/Accessibility/SmokeTesting has some ideas.

Comment 47 Andrew John Hughes 2016-01-29 17:13:55 UTC
I think this is a legacy requirement that could be removed.

On RHEL 6, which has GNOME 2:

# Java Access Bridge for GNOME build requirements.                                                                   
BuildRequires: at-spi-devel
BuildRequires: gawk
BuildRequires: libbonobo-devel

These aren't there for OpenJDK but for the GNOME Access Bridge. As that was for GNOME 2, and Fedora is now on GNOME 3, I think you could just remove this. 

On RHEL 7, it seems the access bridge and Bonobo dependency have gone but not at-spi-devel. This seems like a mistake but I'll double-check.

The access bridge is java-access-bridge-1.23.0.tar.bz2 in sources, and you can remove this and the rules pertaining to it, if it's still there.

at-spi has dependencies on the GNOME 2 libraries:

Requires: gtk2 >= %{gtk2_version}
Requires: libbonobo >= %{libbonobo_version}
Requires: ORBit2 >= %{orbit2_version}
Requires: gail >= %{gail_version}
Requires: atk >= %{atk_version}

some of which have probably gone as well, so I wouldn't try packaging it in COPR.

The replacement is the java-1.7.0-openjdk-accessibility package, which depends on java-atk-wrapper. That, in turn, depends on the replacement for at-spi for GNOME 3:

BuildRequires:  at-spi2-atk-devel
BuildRequires:  at-spi2-core-devel

Comment 48 Julius Schwartzenberg 2016-02-01 12:05:46 UTC
OpenJDK 1.6 still has the libbonobo-devel BuildRequires on RHEL 7. For 1.7 it is removed.

Removing the whole access bridge block indeed gives me a working (1.6) build! I'll try to get the packages in copr soon.

Comment 49 Julius Schwartzenberg 2016-02-05 15:36:14 UTC
Created attachment 1121420 [details]
patch for OpenJDK 1.6.0 u38

Packages for Fedora 23 are in copr now.

I had to add multiple BuildRequires to the spec file to get the build to work. I'm surprised the RHEL builds can work without them.

Comment 50 Julius Schwartzenberg 2016-02-05 15:36:50 UTC
Created attachment 1121421 [details]
patch for OpenJDK 1.7.0 u95 spec file for Fedora 23

Comment 51 Andrew John Hughes 2016-02-05 19:19:57 UTC
Which RHEL are you syncing against? RHEL 7 is going to be closer to Fedora than RHEL 6, but both will be different as these are stable platforms while Fedora constantly changes.

The execstack dependency is a swap for prelink, but neither is required; you'll see there is no execstack call in the spec file any more.

The XRender and freetype ones were probably being pulled in by the bridge dependencies that were removed. I see freetype-devel on the OpenJDK 8 RHEL 7 builds, but not XRender. I think that backend is optional so that may be a regression which I'll look into.

The RHEL builds only get updated at the quarterly security updates and these changes tend to be limited to what's needed so as not to break anything when we're under strict time restrictions. Hence, stuff like this doesn't get cleaned up.

Thanks for this feedback and I'll try and remove some of these dead dependencies.

Comment 52 Julius Schwartzenberg 2016-02-07 00:18:56 UTC
I'm basing everything on the RHEL (CentOS) 7 source RPMs. It seemed the most appropriate source.

Without adding a BuildDepends for execstack, the build fails (on copr) for Fedora 23 with a "command not found" for execstack. (With it, it fails for Fedora 22 because it doesn't have the execstack package.)

In the attached patches I really add the minimum amount of dependencies to get the builds to finish for Fedora 23 on copr. Without them either it fails during a configure script or it breaks during the build with a missing header file (or command).

You're welcome! Having the necessary spec diff for Fedora become smaller is also nice for me of course.

Comment 53 Andrew John Hughes 2016-02-15 17:58:25 UTC
Yeah, it should be possible to also remove the execstack calls if they're still present. The files are now marked appropriately upstream.

For java-1.6.0-openjdk, I was able to do the following:

@@ -224,17 +226,15 @@ BuildRequires: libXt-devel
 BuildRequires: libXtst-devel
 BuildRequires: libjpeg-devel
 BuildRequires: libpng-devel
-BuildRequires: wget
-BuildRequires: xalan-j2
-BuildRequires: xerces-j2
 BuildRequires: xorg-x11-proto-devel
-BuildRequires: mercurial
 BuildRequires: ant
 BuildRequires: libXinerama-devel
 BuildRequires: rhino
-BuildRequires: redhat-lsb
+# Provides lsb_release for generating identification
+BuildRequires: redhat-lsb-core
 %if %{gcjbootstrap}
 BuildRequires: java-1.5.0-gcj-devel
+BuildRequires: libxslt
 %else
 BuildRequires: java6-1.6.0-devel
 %endif

The wget removal requires a backport of http://icedtea.classpath.org//hg/icedtea6?cmd=changeset;node=e9935e163815 and the addition of --disable-downloading to the configure line:

@@ -385,7 +386,7 @@ export CFLAGS="$CFLAGS -mieee"
 ./autogen.sh
 ./configure %{icedteaopt} --with-openjdk-src-zip=%{SOURCE1} \
   --with-pkgversion=rhel-%{release}-%{_arch} --enable-pulse-java \
-  --with-abs-install-dir=%{_jvmdir}/%{sdkdir} \
+  --with-abs-install-dir=%{_jvmdir}/%{sdkdir} --disable-downloading \
   --with-rhino --with-parallel-jobs=$NUM_PROC --disable-lcms2
 
This is a good idea anyway as it ensures the build won't download its own OpenJDK tarball and is forced to use the one in the RPM sources or fail.

Comment 54 Rob Clark 2016-04-16 11:45:25 UTC
jfyi, if we want fedora to target developers, android is perpetually on an ancient java version (marshmallow is on openjdk-1.7).  And it would be nice not to force users to ubuntu in order to build android.

(not really adding anything constructive to this bug, other than to say +10000 for being able to easily parallel install older jdk versions in fedora)

Comment 55 jiri vanek 2016-04-18 05:59:47 UTC
(In reply to Rob Clark from comment #54)
> jfyi, if we want fedora to target developers, android is perpetually on an
> ancient java version (marshmallow is on openjdk-1.7).  And it would be nice
> not to force users to ubuntu in order to build android.
> 
> (not really adding anything constructive to this bug, other than to say
> +10000 for being able to easily parallel install older jdk versions in
> fedora)

They already are possible to install together. Julius - huge thanx to him for doing it - is keeping copr repo with them .

https://bugzilla.redhat.com/show_bug.cgi?id=1190137#c35



cat /etc/yum.repos.d/alternativeJvms.repo 
[jschwart-openjdk-7]
name=Copr repo for openjdk-6 owned by jschwart
baseurl=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/fedora-$releasever-$basearch/
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-7/pubkey.gpg
enabled=1

[jschwart-openjdk-6]
name=Copr repo for openjdk-6 owned by jschwart
baseurl=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/fedora-$releasever-$basearch/
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/pubkey.gpg
enabled=1

[omajid-openjdk9]
name=Copr repo for openjdk9 owned by omajid
baseurl=https://copr-be.cloud.fedoraproject.org/results/omajid/openjdk9/fedora-$releasever-$basearch/
skip_if_unavailable=True
gpgcheck=1
gpgkey=https://copr-be.cloud.fedoraproject.org/results/omajid/openjdk9/pubkey.gpg
enabled=1


You can install them all together, and switch by alternatives. They are just not available in main repos. I fyou wont to keep them in main repos, brace yourself and take the wand :)

Comment 56 Rob Clark 2016-04-18 13:09:27 UTC
(In reply to jiri vanek from comment #55)
> (In reply to Rob Clark from comment #54)
> > jfyi, if we want fedora to target developers, android is perpetually on an
> > ancient java version (marshmallow is on openjdk-1.7).  And it would be nice
> > not to force users to ubuntu in order to build android.
> > 
> > (not really adding anything constructive to this bug, other than to say
> > +10000 for being able to easily parallel install older jdk versions in
> > fedora)
> 
> They already are possible to install together. Julius - huge thanx to him
> for doing it - is keeping copr repo with them .
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1190137#c35
> 

oh, awesome.. I suppose this should be better publicised so it actually shows up when someone searches for 'openjdk 1.7 fedora'

> 
> You can install them all together, and switch by alternatives. They are just
> not available in main repos. I fyou wont to keep them in main repos, brace
> yourself and take the wand :)

heh, fair enough.. but there are a limited number of wands I can hold at one time ;-)

Comment 57 jiri vanek 2016-04-18 16:30:00 UTC
> > (In reply to Rob Clark from comment #54)
> > > jfyi, if we want fedora to target developers, android is perpetually on an
> > > ancient java version (marshmallow is on openjdk-1.7).  And it would be nice
> > > not to force users to ubuntu in order to build android.
> > > 

This slipped a bit form previous reading. There is no need to do so. You can create for any ancient android on openjdk8 - as it is ready on Fedora.

I *do* develop for android pretty much. You set the version of lowest supported in Android Studio, and JDK (which is ready for this) do the rest.

Comment 58 Rob Clark 2016-04-18 17:09:06 UTC
(In reply to jiri vanek from comment #57)
> > > (In reply to Rob Clark from comment #54)
> > > > jfyi, if we want fedora to target developers, android is perpetually on an
> > > > ancient java version (marshmallow is on openjdk-1.7).  And it would be nice
> > > > not to force users to ubuntu in order to build android.
> > > > 
> 
> This slipped a bit form previous reading. There is no need to do so. You can
> create for any ancient android on openjdk8 - as it is ready on Fedora.
> 
> I *do* develop for android pretty much. You set the version of lowest
> supported in Android Studio, and JDK (which is ready for this) do the rest.

hmm, I wonder what is different for apps?  I was just building latest AOSP, and it specifically checks for 1.7 (and build seems to explode with a lot of java issues if I try to bypass that..).  I guess it's at least nice if this issue only effects people trying to build android, vs trying to build android apps.

Comment 59 Julius Schwartzenberg 2016-05-10 14:06:26 UTC
Created attachment 1155768 [details]
patch for OpenJDK 1.6.0 u39 (Fedora 23)

I had to add another BuildRequires this time to get the OpenJDK 1.6 u39 build going on Fedora 23, this time it was libXcomposite-devel.
I've attached a new patch for this.

Comment 60 Julius Schwartzenberg 2016-05-10 16:07:08 UTC
Created attachment 1155788 [details]
patch for OpenJDK 1.7.0 u101 (Fedora 23)

OpenJDK 1.7 also required the extra libXcomposite-devel BuildRequires and a change to cope with the number of update digits going from 2 to 3.

I made only Fedora 23 AMD64 builds. If anybody needs any other builds, let me know and I'll try to let COPR build them as well.

Comment 61 Julius Schwartzenberg 2016-06-21 16:05:11 UTC
There are build issues with the 1.6 source on Fedora 24:

https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/fedora-24-x86_64/00360625-java-1.6.0-openjdk-legacy/build.log.gz

It appears to be this issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1306558

As this is not fixed yet, I'm not sure what kind of 1.8 build is included with Fedora 24 now, but I guess I can try a build with that spec file patch applied.

Comment 62 Severin Gehwolf 2016-06-22 07:25:43 UTC
(In reply to Julius Schwartzenberg from comment #61)
> There are build issues with the 1.6 source on Fedora 24:
> 
> https://copr-be.cloud.fedoraproject.org/results/jschwart/openjdk-6/fedora-24-
> x86_64/00360625-java-1.6.0-openjdk-legacy/build.log.gz
> 
> It appears to be this issue:
> https://bugzilla.redhat.com/show_bug.cgi?id=1306558
> 
> As this is not fixed yet, I'm not sure what kind of 1.8 build is included
> with Fedora 24 now, but I guess I can try a build with that spec file patch
> applied.

The issue in bug 1306558 has been worked-around. However, the underlying issue is that hotspot uses UB which is harder to get fixed (hence, still in assigned). Especially in a stable release. The work-around is to add -fno-lifetime-dse and -fno-delete-null-pointer-check. Upstream bug for JDK 9 is: https://bugs.openjdk.java.net/browse/JDK-8151841

Comment 63 Julius Schwartzenberg 2016-06-22 13:48:15 UTC
I managed to create a 1.6 build on Fedora 24.

In addition to the spec file changes, I had to backport pr2462.patch from 1.8 to 1.6 to let it build with the new GCC 6. A similar patch set seems to be here http://mail.openjdk.java.net/pipermail/build-dev/2016-May/017168.html

The changes go beyond just the spec file now. Is it possible that such changes will appear upstream at some point? In theory I could still put everything in a single patch file against the RHEL source rpm tree, but in a way it's becoming less practical.

As I'd like to continue basing everything off the RHEL sources, I'm wondering in general what's the recommended practice to deal with such a situation.

Comment 64 Andrew John Hughes 2016-06-22 17:11:28 UTC
The GCC 6 changes are something that should happen upstream in IcedTea 2.x/OpenJDK 7 and IcedTea 1.x/OpenJDK 6. Once I have time to look at builds with GCC 6, I intend to get that fixed across all three current JDKs.

Comment 65 Julius Schwartzenberg 2016-06-22 20:07:58 UTC
The build for OpenJDK 7 seems to have gone without issues. I think it already includes the patch.

That means both OpenJDK 6 and 7 are available in copr for Fedora 24 now.

If there's anything I could do to help with getting certain fixes in the right place, please let me know! Of course it would also be nice if some of my spec file changes could go upstream (to RHEL) as well, but I can imagine you're reluctant with that.

Comment 66 Andrew John Hughes 2016-06-23 15:55:21 UTC
If you have a patch for the spec file, I can review it. It's not trivial to get changes into the RHEL RPMs, because they have to be approved. I got some fixes into the upcoming java-1.6.0-openjdk RPM for RHEL 7.3. Now would be a good time to look over a patch as changes could be included with the security update in July if they're not too dangerous.

Comment 67 Julius Schwartzenberg 2016-06-23 20:12:09 UTC
I keep the changes between the RHEL and Fedora spec already as patch files in this bug in general. They also contain the -legacy suffix and other Fedora specific things though. Should I mail you variants without those things?

In general I also tend to not add any changelog entries at the bottom to keep this diff smaller and thus more likely to just apply against a newer RHEL spec. Is this important?

Another possibility would be that I would split the individual changes over multiple diffs. Please let me know what's the best approach!

Comment 68 Andrew John Hughes 2016-06-23 22:38:13 UTC
Yes please. I'd like a patch of whatever you would like applied to the RHEL spec files basically. You don't need to worry about a Changelog; I'll write one and credit you.

Comment 69 Julius Schwartzenberg 2016-06-24 12:34:06 UTC
Created attachment 1171950 [details]
patch for OpenJDK 1.6.0 u39 (Fedora 24)

I mailed you the changes that would be nice to have upstream. I'm attaching the current spec file patches for Fedora 24 here now

Comment 70 Julius Schwartzenberg 2016-06-24 12:34:42 UTC
Created attachment 1171951 [details]
patch backported from 1.8 to solve GCC 6 compile issues

Comment 71 Julius Schwartzenberg 2016-06-24 12:35:27 UTC
Created attachment 1171952 [details]
patch for OpenJDK 1.7.0 u101 (Fedora 24)

Comment 72 Julius Schwartzenberg 2016-07-29 14:49:09 UTC
I just pushed 1.7.0.111 for Fedora 24 AMD64. I could use my patch for 101 without any changes.

I didn't see any response to my mail anymore btw. if you're still interested, let me know if there's anything I could still do. I expect it'll make supporting OpenJDK 1.7 (and 1.6) on RHEL 8 easier as well when the Fedora and RHEL spec files are more in sync.

Comment 73 Andrew John Hughes 2016-07-29 16:56:21 UTC
I've been very busy making those updates you just picked up... :P
I'll take a look again when 6 is done.

FWIW, the new 6 & 7 releases will work out of the box with GCC 6. You shouldn't need any additional patches.

Comment 74 Julius Schwartzenberg 2016-09-09 15:36:27 UTC
Created attachment 1199522 [details]
patch for OpenJDK 1.6.0 u40 (Fedora 24)

Alright :)

Here the patch for the new OpenJDK 1.6 as well. It indeed compiled without the extra patch! Thanks!!

This version is also available from the copr repo now.

Comment 75 Julius Schwartzenberg 2016-11-09 13:55:00 UTC
Created attachment 1218963 [details]
patch for OpenJDK 1.6.0 u40 1.13.12.9 (Fedora 24)

The OpenJDK 6 & 7 versions released with the new RHEL 7.3 are also available for Fedora 24 now.

Comment 76 Julius Schwartzenberg 2016-11-09 13:55:39 UTC
Created attachment 1218964 [details]
patch for OpenJDK 1.7.0 u121 (Fedora 24)

Comment 77 Andrew John Hughes 2016-11-10 02:56:23 UTC
The GCC 6 CFLAGS (final hunk) shouldn't be necessary. The latest IcedTea 2.6.8 / OpenJDK 7 u121, and indeed the prior release, build fine on GCC 6, as I test with that locally.

Comment 78 Julius Schwartzenberg 2017-02-14 16:05:03 UTC
Created attachment 1250289 [details]
patch for OpenJDK 1.6.0 u41 (Fedora 25)

I can confirm it works. Here is the new 1.6 patch with the last hunk removed. Both the latest 1.6 and 1.7 are in copr now. (1.7 didn't need a new patch.)

There's a problem with the recent 1.7.0 (Fedora 25) builds though, the file /usr/lib/jvm/java-1.7.0-openjdk-legacy-1.7.0.131-2.6.9.0.fc25.x86_64/jre/lib/resources.jar is only readable for root, not for any other users. I do not see this problem on RHEL 7. Did anything change regarding file permissions and packaged files on Fedora 25? Other files in the same directory do seem to have the correct permissions.

Comment 79 Julius Schwartzenberg 2017-08-18 20:45:57 UTC
The above problem was probably caused by me building the source rpms as root instead of a regular user. I was using a Docker container and was too lazy to create a builder user the previous time. The current release and the previous release shouldn't have had this problem anymore. For Fedora 25, the 151 version of 1.7 is available now.

In Fedora 26 there's a new version of Ant which requires running in 1.8 and breaks the build of 1.6 and 1.7. Installing the previous version allows the builds to work again. I'll look into getting this building on COPR. I've put some initial packages for 1.6 here: https://schwart6.home.xs4all.nl/fedora26/binaries/
The packages for Fedora 25 should also work on 26.

It seems more packages in Fedora are being built to run against 1.8 now. If there really are people who depend on JARs in /usr/share/java to be compatible with 1.6 or 1.7 it would probably make sense to switch to the software collections (SCL) infrastructure instead of relying on alternatives. I do not have any experience with this however (only used SCLs, never created packages for them) and it's not really needed for my use case.


Note You need to log in before you can comment on or make changes to this bug.