-1

I strongly oppose this approach. Many people raised concerns about building on EPEL 8 (!) and shipping those binaries on Fedora. But even building on Fedora "oldstable" and shipping across all branches, this basically opts OpenJDK out of all System-Wide changes. These concerns have not been addressed at all, which makes this change feel like a foregone conclusion.

I have no strong opinion about building on the oldest supported Fedora (we currently let packages that FTBFS since then in the distro anyway), but -1 for building in EPEL.

-1 for building on EPEL as well

@ngompa The java-latest-openjdk built in epel, and repacked for fedora is not hard demand. it jsut benefit. I have no issue to built java-latestopejdk twice - once in oldest live fedora and repack in fedoras, and once in oldest epel, and repack in epels. I answered it in the question in devel thread and also had adapted the proposal acordingly - https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=679032&oldid=679016

@decathorpe the only thing we will pratically miss is new gcc. And tbh I will regret it too, on contrary it wil save me from false negative build issues, when actually gcc was guilty,, and not jdk (although it is 1 from 100, otherwise new gcc finds issues in jdk). As a middle ground I would liek to keep building also in rawhide, but do not use this in repack - which obviously do not clear your concern.
As for the flags - we are opting most of them out anyway. BAd luck for a decade - jdk is to sensitive to them.
I have replied both of those in the devel thread, ano other concern was rised on this topic. Do you have any more?

(at)epel - I see the generally negative facing to it, so I will adjust the proposal that also java-latest-openjdk will bebuilt twice - once in oldest live fedora, and once in oldest possible epel.

Please, revote. TY!

epel reworked:
https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=679492&oldid=679471
https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=679493&oldid=679492

The proposal has already been amended, but I just wanted to note that I also considered building on EPEL a non-starter. Building Fedora packages should not require a non-Fedora operating system, much less one a commercially-licensed one.

In the devel thread, Robert Marcano asked,

Maybe Fedora should just package the latest JDK needed for Android
development and the latest LTS version. An even the Android (11 I think)
could be skipped because Android Studio includes a build of it. If there
are packages still requiring old things, help to update them could be
offered by packagers, or dropped from the distribution.

I didn‘t notice any follow-up to that suggestion. Do you have any comments on the proposal to reduce the workload by building fewer JDK versions but building them on all Fedora releases, rather than building the same number of JDK versions and building them on only one Fedora release?

I replied at that time: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/Y5ZTJYXSKLJHWZG72C53OFAPBADBOFMM/

I don't really understand this argument - there's no reason to still ship OpenJDK 8 (or 11, for that matter) on Rawhide. Keeping old versions around forever isn't a good way to spend your time, I think ...

For example, if all OpenJDK versions older than the new default were removed from Fedora one release after the switch to the new version, that should result in something like this fictional scenario:

• Fedora 33: Switch to OpenJDK 11
• Fedora 34+: OpenJDK 8 removed
• Fedora 36: Switch to OpenJDK 17
• Fedora 37+: OpenJDK 11 removed

There's also the question about whether it makes sense to ship new OpenJDK versions on all branches of Fedora instead of just new ones.

The current approach of everything, everywhere, all at once is a lot of work for little gain, that I agree with, but that workload could be about halved by 1. removing old OpenJDK versions once they have been obsolete for a while, and 2. only packaging new OpenJDK versions on new branches.

As you said, Fedora is supposed to be leading edge - which is why I don't understand why you keep ancient OpenJDK versions around forever, and package new ones on old branches. I'd much prefer a more "leading edge" approach to reducing your workload rather than keep piling on hacks and workarounds that objectively make the value-add of Fedora OpenJDK packages compared to upstream smaller and smaller.

I must confess I don't know much about our users -- Java developers. But with Python, we do everything, everywhere, all at once because we want our users to be able to test their software with old and new Pythons.

True, but as far as I know, you don't need to run 24 hours of certification tests for every build just to be able to ship them as "Python" instead of Snake lang :)

Sure, we don't. I just wanted to share a similar use case.

I might be wrong here, but I'd guess that there are orders of magnitude more people developing Python on Fedora than there are Java developers. Popular Java IDEs don't even use system JDKs at all - Eclipse is no longer shipped as an RPM and the Flatpak uses the OpenJDK Flatpak runtime extension, and IntelliJ bundles its own JDK.

Long story short, the cost benefit analysis for shipping lots of OpenJDK versions vs. shipping all supported Python versions is completely different.

You can still download intelij without JDK, and that is what I think every reasonable linux user does. But this is just personal opinion (I do that :)
the everything everywhere is more over aligned with what @churchyard said.

Reduction of JDKs is option. The keeping of different jdks in different fedoras is - except system jdk - nonsense. We will try to keep java-latest-openjdk in supported conditions, and system JDK. If t it goes bad, it may turn down to only one of them (which is 4 builds in pure rpms, so the acceptable limit I''m asking for 4 jdks, built once, in the proposal.)

I'm sorry, but the second paragraph throws parsing exceptions in my brain.

Either way, I said it when we approved Part 1 of this proposal, and I haven't changed my mind. This is bad and I won't vote for it. You seem to be teflon-coated regarding any alternatives that we suggest, so continuing to talk is probably not productive.

I will refrain from commenting here further, but my -1 vote stands.

I have tried to fix typos and grammar i that comment, hopefully it helps a bit. Otherwise sure, TY, and please continue to keep Fedora great distro as you are doing.

I would opose that I resists to the alternatives, but I do not see them as alternatives. We have an option build 4 jdks once, or one jdk four times. Thats moreover all. Where the second - one jdk fourtimes - I consider much worse, and am highlighting that it is nearly impossible to live only with one jdk, you need at least tow, sometimes three to keep java stack (imho) viable.

I have updated contingency plan: https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#Contingency_Plan / https://fedoraproject.org/w/index.php?title=Changes%2FBuildJdkOncePackEverywhere&type=revision&diff=679828&oldid=679493

I will drop email also to thread.

Sorry for not writing this out of the box. It was written so many times I consider it as "widely known" but obviously I was wrong. Sorry for that.

Tagging for meeting due to negative votes. @jvanek we will discuss this during today's FESCo meeting (in ~2.5 hours, at 17:00 UTC).

Thanx. Please where are yo meeting those times?

The meeting is held in #fedora-meeting room on irc.libera.chat / the "Fedora Meeting" room on chat.fedoraproject.org (both are supposed to work).

tyvm!

We voted on this proposal during today's meeting:

* #3008 Change: Build JDKs once, repack everywhere  (decathorpe,
  17:06:59)
  * AGREED: REJECTED (+4, 0, -2): Change proposal is not accepted as-is
    (decathorpe, 17:36:50)
  * AGREED: AGREED (+6, 0, -0) The change owners will discuss the actual
    workflow with rleng and update the change proposal accordingly,
    resubmitting it when ready.  (decathorpe, 17:44:37)

Hello!

I had investigated bodhiudpatability:
https://pagure.io/releng/issue/11438#comment-862079
https://pagure.io/releng/issue/11438#comment-862108

its very long run solution. Beofore it is implemented, (year+, if ever), I come with workaround for missing portbles i release - https://pagure.io/releng/issue/11438#comment-862328

If you would be so kind and review it, I would amend the proposal and reopen this ticket for your next meeting.

https://fedoraproject.org/wiki/Changes/BuildJdkOncePackEverywhere#including_portable_srpms_in_release_(improving_of_step_6)