Add JREs to linux packaging system (feature request)

[theofficialgman]

Now that #330 is officially closed, and requests for JREs on the DEB/RPM repos were not fulfilled, I have created a new issue to track this suggestion.

JREs support was requested or mentioned in these locations:
#330 (comment)
#330 (comment)
#330 (comment)

[karianna]

For those watching, linuxNew has been renamed to linux

[Jeeppler]

To have Linux packages available is awesome, but JREs are really missing. JREs builds are a lot smaller compared to JDK builds.

[ascheman]

Please assign this to me (@smlambert) as discussed.

[ascheman]

I have some questions wrt. to implementation options and would be happy about some feedback.

Please checkout my changes at master...ascheman-adoptium:installer:feature/430-poc-1-debian-jre-src

I started with a first PoC for Debian as I can see at least two implementation options:

1. Make a copy of all current src packages, e.g., 8 -> 8-jre (as I did here)
2. Parameterize the package in the given srcs. It should be possible to perform a paramterized build (since it is mostly based on a large GNU makefile).

I see drawbacks with both approaches:

1. A lot of stuff is duplicated and needs to be maintained redundantly. Therefor the code is a little simpler/better to understand for people without a strong Debian/make background.
2. Over the time it would look a little bit like the codebase of the official Debian JDK/JRE build which makes maintenance a little harder. If this approach was used, it perhaps would be consequent to merge all different JDK/JRE package builds into a single directory instead of having one per JDK version.

If desired, I could provide a second PoC to show an implementation of the second variant. But probably the team already has a preference and could meet a decision how to proceed.

Besides this I do have some more questions, but this is the most important one.
Let's concentrate on this decision before proceeding.

And, of course, I will refactor/clean up my changes before raising a final pull-request.

[smlambert]

FYI @sophia-guo @jerboaa (upon your returns from vacation on Jan 9th) - may I ask your input to Gerd's questions above please :)

[jerboaa]

I cannot really comment on the debian packaging approach as I have basically no experience there. Having said that, it seems fine to duplicate installer files into <version>-jre dirs and have it maintained there. I'd expect the list of installed alternatives to differ for JDK vs. JRE anyway. My $0.02.

[sophia-guo]

For debian probably @gdams is the right person to help. I have no experience about it.

[tellison]

I'll jump on the bandwagon of not being experienced in Debian best-practices, bit looking at the PoC changes, it is probably better to accept the duplication and keep it simple - since any changes will have to be understood by the folks here who are not Debian installer experts. If we are lucky to attract somebody who is willing to take ownership of this space then the decision may change and the code can be optimised further.

[ascheman]

Thanks for the feedback, @tellison !

Then I'll go ahead and will provide similar changes for all the other Linux repositories, starting with Debian.

[ascheman]

Thinking of it again, I finally suggest to put everything JRE-related into a completely parallel tree:

Existing

linux/
├── Jenkinsfile
...
├── jdk
│   ├── alpine
│   ├── build.gradle
│   ├── debian
│   ├── redhat
│   └── suse

New

linux/
...
├── jre
│   ├── alpine
│   ├── build.gradle
│   ├── debian
│   ├── redhat
│   └── suse

And have Gradle tasks packageJreDebian etc.

[Jeeppler]

Alpine smoke tests works well for:

• 8u362
• 11.0.18
• 17.0.6
• 19.0.2

[askmike1]

I see this has been closed, but I'm not seeing any JRE packages at https://packages.adoptium.net/ui/native/rpm/centos/7/x86_64/Packages/, has this been released?

[smlambert]

My expectation is that we will run a job tomorrow to publish these (once a few more of my PMC colleagues give it a +1 to publish).