Skip to content

Conversation

@judovana
Copy link
Contributor

@judovana judovana commented Jan 2, 2026

Code for #917 (comment)

The PR itself is still not yet considered "ok", many testing ahead and many things to agree, but serves as example of both jre and jre-headless from one specfile:

rpmbuild -bb temurin-21-jre.spec
...
 rpm -q --requires .../rpmbuild/RPMS/x86_64/temurin-21-jre-21.0.9.0.0.10-1.x86_64.rpm 
/bin/sh
/bin/sh
/bin/sh
/usr/sbin/alternatives
alsa-lib(x86-64)
ca-certificates
dejavu-sans-fonts
fontconfig(x86-64)
glibc(x86-64)
libX11(x86-64)
libXext(x86-64)
libXi(x86-64)
libXrender(x86-64)
libXtst(x86-64)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
zlib(x86-64)
rpmbuild -bb temurin-21-jre.spec --without headfull
...
 rpm -q --requires .../rpmbuild/RPMS/x86_64/temurin-21-jre-headless-21.0.9.0.0.10-1.x86_64.rpm
/bin/sh
/bin/sh
/bin/sh
/usr/sbin/alternatives
ca-certificates
glibc(x86-64)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
zlib(x86-64)

I think many of the X dependencies are not necessary, as they should be autogenerated, but am not going to touch those:). Also note the name - something to confirm.

I'm not sure with alsa-libs and dejavu-sans-fonts but am sure with fontconfig dependence. For alsa and dejavu, they shoudl be probably suggests in newer RPMs, but as also older rpm without suggests/recommends is supported, then I think it would be better to leave them out. its easy to install them on top, but hard to remove if they are hard-coded.

I'm also not sure, how to init another pipeline. I would probably parametrize https://github.com/adoptium/installer/blob/master/linux/jre/redhat/src/main/packaging/build.sh to eb able to produce both headfull and --without headfull or enhance it so it produce both right away, rather then add any duplicates. Any hints or help on the "how this should be consumed", welcomed.

Also I guess I should be editing the https://github.com/adoptium/installer/tree/master/linux_new/jre/rhel/src/main/packaging and not this one.. But am not sure

@@ -1,13 +1,16 @@
%global upstream_version 21.0.5+11
%global upstream_version 21.0.9+10
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should not be there, but api did not yield the 5+11 for me today.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems odd that this isn't already at the latest...

@jiekang
Copy link
Contributor

jiekang commented Jan 2, 2026

Please link the pull request to the issue as described by the guide here:
https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue

Thank you!

@jiekang
Copy link
Contributor

jiekang commented Jan 2, 2026

Also, the Linux installers are undergoing a rewrite where spec files are being generated on demand rather than individually maintained under the "linux_new" folder.

See:
https://github.com/adoptium/installer/tree/master/linux_new
https://github.com/adoptium/installer/blob/master/linux_new/generate_spec.py
https://github.com/adoptium/installer/tree/master/linux_new/jdk/rhel/src/main/packaging/temurin/25

I expect your changes will need to be done there. But it's nice to see how simple the spec macros are in order to add a headless package. I would add that as a comment to this PR so reviewer's can reference it.

@judovana
Copy link
Contributor Author

judovana commented Jan 2, 2026

resolves #917

@judovana
Copy link
Contributor Author

judovana commented Jan 2, 2026

Also, the Linux installers are undergoing a rewrite where spec files are being generated on demand rather than individually maintained under the "linux_new" folder.

See: https://github.com/adoptium/installer/tree/master/linux_new https://github.com/adoptium/installer/blob/master/linux_new/generate_spec.py https://github.com/adoptium/installer/tree/master/linux_new/jdk/rhel/src/main/packaging/temurin/25

I expect your changes will need to be done there. But it's nice to see how simple the spec macros are in order to add a headless package. I would add that as a comment to this PR so reviewer's can reference it.

hi! yes, I noted the j2 "specfiles". But there are still one specfile per jdk and while reading all that related .sh and .gradle, I have not grabbed which one is actually used (see the last paragraph of summary). So modyfing directly the "old" spec was more direct. And as you write - the change is nicely visible.

@jiekang jiekang requested a review from steelhead31 January 5, 2026 13:15
Copy link
Contributor

@steelhead31 steelhead31 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is functionality we want in the temurin releases, we'll need to update the version specific templates in the linux_new folder. If we definitely want this, Im happy to do these changes on this PR ahead of the january release cycle!

@judovana
Copy link
Contributor Author

judovana commented Jan 5, 2026

If this is functionality we want in the temurin releases, we'll need to update the version specific templates in the linux_new folder. If we definitely want this, Im happy to do these changes on this PR ahead of the january release cycle!

Can you plsae drop how to test the j2 changes? Also There is quite a lot to decide (I had moved the "decission" non technical discussion back #917 (comment) , before I noticed this comment)

I will mgrate it to j2 in menatime, as the chages are moreover identical.

@steelhead31
Copy link
Contributor

If this is functionality we want in the temurin releases, we'll need to update the version specific templates in the linux_new folder. If we definitely want this, Im happy to do these changes on this PR ahead of the january release cycle!

Can you plsae drop how to test the j2 changes? Also There is quite a lot to decide (I had moved the "decission" non technical discussion back #917 (comment) , before I noticed this comment)

I will mgrate it to j2 in menatime, as the chages are moreover identical.

To test this I create a test jenkins job, and amend the jenkinsfile so that it doesnt push packages to artifactory..

https://ci.adoptium.net/job/build-scripts/job/release/job/sfr-build-linux-package-modular/

Once all the changes are in, Im happy to run the above job against your fork/branch, theres a few changes needed to the jenkins file.. ( https://github.com/adoptium/installer/blob/master/linux_new/Jenkinsfile ) to comment out the jfrog upload..

Line 192

// jf 'rt u ${FILENAME} deb/pool/main/t/temurin-${RELNUM}/ --target-props=${DISTROLIST}deb.component=main;deb.architecture=${BUILDARCH} --flat=true'
Line 204

// jf 'rt u **/build/ospackage/${FILENAME} apk/alpine/main/${BUILDARCH}/ --flat=true'

Line 215

// jf 'rt u ${FILENAME} ${PACKAGEDIR}/ --flat=true'

And these too..

Lines 991 - 993

//                  build job: 'publish_linux_pkg_src', parameters: [
//                      string(name: 'TAG', value: params.TAG),
//                      string(name: 'FILENAME', value: ArchiveFileName)
somethi

Let me know if you want me to help test, the job in question is restricted in jenkins, but I've already got the above set up, would just need the changes above, and a small change in jenkins to point to your branch

@judovana
Copy link
Contributor Author

judovana commented Jan 5, 2026

I will mgrate it to j2 in menatime, as the chages are moreover identical.

To test this I create a test jenkins job, and amend the jenkinsfile so that it doesnt push packages to artifactory..

...

Let me know if you want me to help test, the job in question is restricted in jenkins, but I've already got the above set up, would just need the changes above, and a small change in jenkins to point to your branch

Yes, I will need help. I got lost already on " create a test jenkins job," :((( Will change the PR to aim the j2 files.
The j2 files do not have jdk8 - so "old" jdk8 specifies shold be affected?

Thanx a lot for all the hints!

@steelhead31
Copy link
Contributor

The JDK8 specfile templates(j2) should be here.. https://github.com/adoptium/installer/tree/master/linux_new/jre/rhel/src/main/packaging/temurin/8

If you make the template changes, I'll make the changes to the jenkinsfile on your branch for testing to build the headless packages, and then run some builds for jenkins.

Are these changes just for the RHEL based RPMs, or do the SLES ones require the same changes ?

@judovana
Copy link
Contributor Author

judovana commented Jan 5, 2026

The JDK8 specfile templates(j2) should be here.. https://github.com/adoptium/installer/tree/master/linux_new/jre/rhel/src/main/packaging/temurin/8

:face_palm:

If you make the template changes, I'll make the changes to the jenkinsfile on your branch for testing to build the headless packages, and then run some builds for jenkins.

yyy. Will give you note. TYVM!

Are these changes just for the RHEL based RPMs, or do the SLES ones require the same changes ?

Hmm. Good question. I was not thinking about suse for now. Although they should be easily adjsuted, I would wait with it for some seen interest, or at least as another changeset. I was actually wondering why there are two sets (rhel/suse) of specfiles... Note that the change is also applicable for debian and others. But would really wait untill there is some interest (unless it is provided as feature). If SLES is not suse, please correct me :)

%global priority 2100

# if rpmbuild will be executed as `rpmbuild -bb ...spec --without headfull ...` then headless package will be generated
%bcond_without headfull
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's headful not headfull

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanx!! Will fix in next iteration

@@ -1,13 +1,16 @@
%global upstream_version 21.0.5+11
%global upstream_version 21.0.9+10
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems odd that this isn't already at the latest...

@judovana
Copy link
Contributor Author

judovana commented Jan 6, 2026

seems odd that this isn't already at the latest...

Thats becasue I edited unused .spec. The .j2 files should be edited instead. Will do once PMC accept it (or not do, once tey decline it)

@steelhead31
Copy link
Contributor

@judovana this has been discussed and agreed with the PMC, if you'd like to update the specfiles in this branch, im happy to contribute the jenkins changes, and build some test packages using my test jobs in jenkins, assuming everything goes ok we can then plan implementing it :)

@judovana
Copy link
Contributor Author

judovana commented Jan 8, 2026

@judovana this has been discussed and agreed with the PMC, if you'd like to update the specfiles in this branch, im happy to contribute the jenkins changes, and build some test packages using my test jobs in jenkins, assuming everything goes ok we can then plan implementing it :)

@steelhead31 Ok, moved the change to j2 file. Can you please ride your magic wheels? If we would be ok with the change, will spread it to 25,26,17,11 and 8.

I had added also an clumsy attempt to build jre and jre-headless in loop. WDYT? I feel slightly losst. Anything tried/advised will be highly appreciated.

@steelhead31
Copy link
Contributor

@judovana I'd remove the loop to build jre & jre-headless, I can handle this in the jenkinsfile for the automated production process :) .. I'll make some changes this afternoon and update you later

@steelhead31
Copy link
Contributor

In fact, I've already almost allowed for this in my jenkinsfile..

def packageTypes = ['jdk', 'jre']
now becomes
def packageTypes = ['jdk', 'jre', 'jre-headless']

@judovana
Copy link
Contributor Author

judovana commented Jan 8, 2026

Cool! Sure! ty!

@judovana
Copy link
Contributor Author

judovana commented Jan 8, 2026

Reverted. Once you are ready, please show me how the jre-headless evolve to --without headful later. Am extremely curios. TYVM

@steelhead31
Copy link
Contributor

Reverted. Once you are ready, please show me how the jre-headless evolve to --without headful later. Am extremely curios. TYVM

Thanks, I will do.. Im just evaluating where the best place to make the change is.. I suspect its actually going to be in the gradle, but once I've done a bit of investigating, I'll let you know.. Ive just contributed the change to prevent anything getting uploaded to anywhere it shouldnt, and I'll test that.. then have a look at which bit of the build needs tweaking

judovana and others added 3 commits January 9, 2026 09:33
@judovana
Copy link
Contributor Author

@steelhead31 I had removed also policytool, which is gui application. It should not cause any troubles, but am looking forward for testing bits.

@steelhead31
Copy link
Contributor

I'll produce a couple of versions with this change, and let you have them later today

Copy link

@github-actions github-actions bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A block has been put on this Pull Request as this repository is temporarily under a code freeze due to an ongoing release cycle.

If this pull request needs to be merged during the release cycle then please comment /merge and a PMC member will be able to remove the block.

If the code freeze is over you can remove this block by commenting /thaw.

@judovana
Copy link
Contributor Author

As expected, the removed policytool, results to broken symlink of lrwxrwxrwx. 1 root root 28 Jan 20 18:20 /usr/bin/policytool -> /etc/alternatives/policytool and lrwxrwxrwx. 1 root root 55 Jan 20 18:22 /etc/alternatives/policytool -> /usr/lib/jvm/java-8-temurin-jre-headless/bin/policytool

Still I think the removal is good thing, and would not take any action (eg replacement by bash script or similarly). Note that our headless packages suffers the same. Also note that poliytool is jdk8 specific.

Otherwise the newest jre8 and jre8headless beahves as they should.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants