April CPU - Change Spec Files etc to ship JDK22 s390x Patched Packages #887
Conversation
| @@ -39,7 +39,7 @@ fi | |||
|
|
|||
| # loop spec file originally from src/main/packaging/$product/$productVersion/*.spec | |||
| for spec in "$(ls /home/builder/build/generated/packaging/*.spec)"; do | |||
| spectool -g -R "$spec"; | |||
| spectool -g -R -f "$spec"; | |||
There was a problem hiding this comment.
Its a cludge/workaround to allow for the fact that the rpmbuild process builds ALL architectures regardless of which one is passed in. This is a temporary solution ( thus not to be merged ) to allow the publishing of the packages to be completed. The current plan is to try and make this process a little more consistent ahead of the next release.
| %global vers_arch x64 | ||
| %global vers_arch2 ppc64le | ||
| %global vers_arch3 aarch64 | ||
| %global vers_arch4 s390x |
There was a problem hiding this comment.
Why are all those vers_archX enumerated for each arch? I would guess, that only src_num shoudl be enough (as sha_src_num is jsut src_num+1 wdyt?
There was a problem hiding this comment.
See my previous comment :) , its currently impossible using this spec file , and the one jenkins job to actually publish a patch for a single architecture.. I agree this should be made entirely modular and architecture independent.
There was a problem hiding this comment.
This PR is serving as a documentation piece on what was needed to accomplish it, so that when its redesigned we can improve it significantly.
There was a problem hiding this comment.
No, Im fairly new to all of this rpm packaging, I suspect you know more than I, so if you wouldn't mind helping out when we come to improve this functionality, all help/support will be greatly welcomed!
There was a problem hiding this comment.
I see. Considering I will looking to the headless packgae and versionless provides, I think I should do deep dive into this. I will try to keep myself in loop proeprly.
|
Closed so as to prevent accidental merging. |
Due to the nature of our RPM spec files, I recommend this PR not be merged, Im only opening it to allow the packages to be published..
The debian changes are all ok, and as standard, but due to the implementation methods in the rpm spec files and build script, I recommend this PR not be merged, and will simply be closed to serve as a reminder detailing how this had to be achieved, where only a single architecture receives a patch.