hi!
I'm testing this now, and they all looks good. However the JDK-8 have bad %DIST. It is ok it is repacking binary from f39 (As jdk8 is no longer buildable on f40+ without huge patching), but the repack itself should happen on f41. It is also ok to tag portables to future fedora, but not rpms. It seems I had overlooked it also last time. Sorry.
Please ping me off-lsit to resolve the workflow.
Anyway on x86_64 the install of all packages passed, and all are printing java -version, so karma++
tested as
tester@fedora:~$ koji download-build -a x86_64 java-1.8.0-openjdk-1.8.0.472.b08-1.fc39
tester@fedora:~$ koji download-build -a x86_64 java-17-openjdk-17.0.17.0.10-1.fc41
tester@fedora:~$ koji download-build -a x86_64 java-11-openjdk-11.0.29.0.7-1.fc41
tester@fedora:~$ sudo dnf install *.rpm
tester@fedora:~$ find /usr/lib/jvm/| grep "/bin/java$"
/usr/lib/jvm/java-17-openjdk-fastdebug/bin/java
/usr/lib/jvm/java-11-openjdk-slowdebug/bin/java
/usr/lib/jvm/java-11-openjdk/bin/java
/usr/lib/jvm/java-1.8.0-openjdk/bin/java
/usr/lib/jvm/java-1.8.0-openjdk/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-slowdebug/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-slowdebug/jre/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-fastdebug/bin/java
/usr/lib/jvm/java-1.8.0-openjdk-fastdebug/jre/bin/java
/usr/lib/jvm/java-17-openjdk-slowdebug/bin/java
/usr/lib/jvm/java-11-openjdk-fastdebug/bin/java
/usr/lib/jvm/java-17-openjdk/bin/java
tester@fedora:~$ q=0 ; for x in `find /usr/lib/jvm/| grep "/bin/java$"` ; do java --version || let q=$q+1 ; done ; echo $q
...
0
hi! I understood the issue. If we would be speaking about released Fedora, then it would be real problem. But this is rawhide. To quote: "rawhide eats babies". Rawhide (and its users) can deal with it properly. In stable fedoras there is still jdk24, so any update to 25 will go ok. I had started https://koji.fedoraproject.org/koji/taskinfo?taskID=137641590 which is still suffering the same issue, but afil should go on.
I can bump to 37 out of the box, but i really do not see reason for that. There will be security release at end of October, and jdk will bump at that moment.
"We've always had a policy/rule against updates having a lower version/release than the current package". I'm well aware, and i if one of the conditions I'm bringing up wuld be missing, I woudl not do this. a) its rawhide only. b) its bump from 24->25 so the release will eb always beigger no metter of release. Except rawhide. BUtin rawhide the old build was untagged, and the three unhappy souls which manmaged to installed are no doubts skilled ngineers.
Are you ok with this explanation and step?
Can this be restored or is it mandatory to be rebuild?
I have overlooked what package you are speaking about. This onw was correct. the 2.rolling.fc44. was utagged from rawhide :/
This update has been unpushed.
This update has been unpushed.
This update has been unpushed.
This update has been unpushed.
This update has been unpushed.
This update has been unpushed.
This update has been unpushed.
Correct. Latest will have always lower R then LTS of same major version