#11438 Build JDKs once, repack everywhere
Closed: Fixed a month ago by jnsamyak. Opened 11 months ago by jvanek.

  • Describe the issue
    https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere
    We have to help to build infrasstructure bindings (or how to call that), that we build OpenJDK 8,11,17 and 21 in oldest live fedora, and repack in all live fedoras. Jdk latest (20,22...) would be nice to build in epel8, and repack in all live fedoras and epel9.

  • When do you need this?
    This is f40 system wide change, which once approved, and implemented, will soak also to older live fedoras

  • When is this no longer needed or useful? (YYYY/MM/DD)
    if the system wide change https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere will not be allowed

  • If we cannot complete your request, what is the impact?
    Then approved system wide change will not happen, or will slip to f41 or to eternity. If the feature is not implemented on long run, we will need to drop most of the javas in fedora


Hi, so this ticket states f40 change but the wiki page states target release 39. Which is it?

Metadata Update from @humaton:
- Issue tagged with: changes

11 months ago

Sorry. Typo here. It is f39 change.

Metadata Update from @jnsamyak:
- Issue tagged with: f39

11 months ago

So, there was some confusion/questions/problems around the tagging setup, so we agreed to discuss here, clarify and then you all would resubmit the proposal.

The suggestion/current proposal has:

 1. request side tags for all releases
 2. build the actual Java in the side tag for the oldest thing
 3. tag the result ot (2) to all side tags from (1)
 4. waitrepo them
 5. build the repacked java packages in all the side tags from (1)
 6. untag the result of (2) from all the side tags from (1)
 7. ship bodhi updates from side tags OR retag the builds to candidate tags
    (and delete the side tags)

This would work, and be minimal work for releng. The one downside of this plan is that the openjdk*portable thats built in the oldest fedora and certified could only be shipped in the oldest fedora. bodhi won't let you attach one build to multiple updates.

Possible ways forward:

  1. Just don't worry about this. Only ship the portable rpm in the oldest fedora release.

  2. Use this plan, but in newer fedora releases build a *portable package that just contains a README and summary telling users to install from the oldest stable release.
    This could be done via macros in the spec file, so wouldn't take too much work. Also, these packages wouldn't need to be updated all the time, just so they are 'newer' than the old version with the actual builds in it.

  3. Modify bodhi to allow in some cases attaching the same build to multiple updates. I am not sure how much work this would be, but I suspect it would be... considerable. I don't think we can commit to doing this on any timeframe.

Open to more clever ideas.

Hi Kevin!

Thanx a lot forbrainstorming. From all people in this ticket, I belive I'm most tag-dummy one.
- srpm rebuild have to work. All three items seems to be leading to this result.
-- with (2) what yo suggest it would work, only it will be a bit clumsy and not transaprent, with need of readme. Works for me as temporary solution.
-- with (1) the readme would be in normla rpms, instead of in portable palceholder. I actually consider this as better then the portabel placeholder.
- bodhi modification to allow this, would solve all issues, and it should be the choice for long run
-- Do you know anybody to talk with ?

What if the openjdk*portable package existed on all releases, but only the oldest one would be certified and used to build the repacked packages?

The main reason for doing this is to reduce unnecessary workloads, both for people and machines. This is not just about the testing, but also the build process, which takes in the order of hours to build on all the architectures we support, and the maintenance work of engineers.

Yes, you could build the JDK on every Fedora release and only test the oldest. But why would you? What advantage is there to this? The disadvantage is that someone has to do the work of keeping all those release branches in sync, performing builds for all those branches and then pushing them through Bodhi. And to what gain? Why does a Fedora 39 user need an OpenJDK build made on Fedora 39 rather than 38?

It is common practice within the OpenJDK community for a single build to be made which supports the greatest number of platforms. Many OpenJDK users download a binary which has been built against a glibc much older than anything in any active Fedora release (e.g. see Oracle's setup: https://wiki.openjdk.org/display/Build/Supported+Build+Platforms) So what we are proposing is not unusual from the perspective of OpenJDK users, even if it is unusual from the perspective of other Fedora packages.

That setup of building on every platform makes sense for other Fedora packages where a new Fedora release often means a new package version e.g. you do separate gcc builds for Fedora 38 & 39 because they maintain different versions of gcc. This is not how OpenJDK works. We have a separate package for each major release, which conforms to a different version of the Java specification. Each package receives quarterly security updates on every Fedora release; the alternative would be that the OpenJDK on older Fedora versions would be vulnerable to multiple CVEs.

Regarding the proposed process, I think it sounds sensible and similar to what we have established for this in RHEL & CentOS, but I will let Jiri have the final say as the maintainer for Fedora.

Currently on RHEL/CentOS, we:

  1. Build a portable JDK from a portable branch in a special buildroot
  2. The portable JDK is only tagged into the special buildroot
  3. We build a RHEL 8 RPM in the same special buildroot where it can access the portable
  4. The RHEL 8 RPM is tagged manually as it would be if built in the normal RHEL 8 buildroot
  5. Step 3 & 4 are repeated for RHEL 9 in the RHEL 9 buildroot

The portable JDK never leaves its special buildroot (which differs from Fedora where it is a package that reaches the compose).

I think Fedora could manage without a separate portable package altogether. In RHEL/CentOS, we have one because we have the concept of major versions and so want to build on the oldest major version for the portable (currently RHEL/CentOS 8), but then repackage into an RPM suitable for the latest major release. The individual Fedora versions are much closer than RHEL/CentOS major versions, and more akin to minor RHEL/CentOS releases. For those, we just tag into each minor release or rely on inheritance.

If we require a passing testsuite before shipping and the testsuite cannot run during the Fedora build (say because the testsuite is proprietary and cannot be disclosed publicly), then we cannot build the package in Fedora Koji. A build becomes available to the general public for download immediately after it completes successfully. This is just how Koji works.

I'll try to gather Red Hat's actual requirements and get permission to share them on this ticket.

If we require a passing testsuite before shipping and the testsuite cannot run during the Fedora build (say because the testsuite is proprietary and cannot be disclosed publicly), then we cannot build the package in Fedora Koji. A build becomes available to the general public for download immediately after it completes successfully. This is just how Koji works.

I'll try to gather Red Hat's actual requirements and get permission to share them on this ticket.

I agree. It would not be feasible to build OpenJDK in Koji if this was the case.

The portable JDK never leaves its special buildroot (which differs from Fedora where it is a package that reaches the compose).

Which is bad:
- I consider having portable build available for generic use case as positive thing.
- I consider SRPM rebuild - thus enablement of portables being part of the repos - as crucial

And I don't suggest such a thing for Fedora. What I suggested above was that a separate portable package could be avoided altogether in Fedora; just build the usual java-<x>-openjdk package on the oldest Fedora.

Do we have an usage statistics for the *-portable packages? Are people actually installing them?

What if the openjdk*portable package existed on all releases, but only the oldest one would be certified and used to build the repacked packages?

Actually after thinking about this 3times, it may be working. By doing so, I will not lost the track with rawhide changes. I do not know how the certification. Ineed to discuss this.

The portable JDK never leaves its special buildroot (which differs from Fedora where it is a package that reaches the compose).

Which is bad:
- I consider having portable build available for generic use case as positive thing.
- I consider SRPM rebuild - thus enablement of portables being part of the repos - as crucial

And I don't suggest such a thing for Fedora. What I suggested above was that a separate portable package could be avoided altogether in Fedora; just build the usual java-<x>-openjdk package on the oldest Fedora.

That is not possible without releng. One of the goals of this proposals it so be abel to do an updates withotu relengs.
It is possible via https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#theoretical_tagging_solution with disadvantage, that portabels will not be in updates. Which means srpm rebuild broken. The remaining goal in this proposal is to at least try to do it better. Bringing fedora releng back, is not a possibility.

Do we have an usage statistics for the *-portable packages? Are people actually installing them?

I consider them as useful, and future replacement for parallel installs.

Bodhi issue https://github.com/fedora-infra/bodhi/issues/5387 investigating possibility to deliver single build as update to several releases.

"It's not possible ATM, it would require a heavy rewrite of the code, starting from the database structure (every build is now related to a single release)..." Maybe on long run...

Sounds like I will need to go with comment in rpms saying where to find portables for repack, xor build portables for each fedora but do not ship, or kindly ask relengs to re-tag portables from time to time (if bigger change appears in theirs sepcfile) to all forward fedoras or.

Actually anti idea - If I will be building, portbales everywhere (which will not be shipped), and then do the tag dancing - will there not be a clash of two portables? Although I guess higher version will simply win.

As for the download of portables in case of oldest fedora build only, the generated readme may be good enough to pinpoiint as exactly as one-click (wip)

Yeah, so back to the first ideas then...

Yes, if you build for multiple releases the resulting packages should use %{?dist} and thus .fc37, .fc38, .fc39 and so would be rpm 'newer' even though they are the same version.

I was playing a bit with dynamically generated SRPM_REBUILD.readme , which would pinpoint directy to correct portable package, and I think I will go with it.
If there will become complains about missing proper srpm rebuild, then I will move building poratbles for each live OS, but keep repacking only the one from oldest.
AFAIC, the dissussion in bodhi team is still running. If the feature will be evere implemented, I wil move to this solution.

if FESCO people is ok with this approach, please state your opinions here, I willa djsut the proposal acordingly.

I don't know that all fesco folks are following this. Perhaps it's worth adding to the thread on the devel list?

You are correct. I will update Fesco ticket.

any news on this? it's an F39 Change, but doesn't seem to be...happening. I've recommended to FESCo that it be deferred to F40 - https://pagure.io/fesco/issue/3059#comment-875161

hi. Sorry for delay. Yes, it slipped to f40, but I'm back on track.

Metadata Update from @jnsamyak:
- Issue untagged with: f39

a month ago

Hello,

Thanks for opening this ticket and looping us in, I don't think we have anything elsefrom the releng side that needs much changing. Closing this, but feel free to open this in case of any issues.

Metadata Update from @jnsamyak:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

a month ago

Login to comment on this ticket.

Metadata