This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. Jdks in fedora are already static, and we repack portable tarball into rpms. Currently, the portbale tarball is built for each Fedora and Epel version. Goal here is to build each jdk (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and repack in all live fedoras. == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jvanek(a)redhat.com == Detailed Description == As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. As described in same wiki page, and individual sub changes and devel threads, with primary reason this - to lower maintenance and still keep fedora java friendly. * In first system wide change, we had changed JDKs to build properly as standalone, portable jdk - the wey JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went usptream, but it become fight which can not be win * as a second step we introduced portable rpms, which do not have any system integration, only builds JDK and pack final tarball in RPM for free use. * In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated rpms. Instead of this, normal RPMS BUildRequire portable rpms and just unpack it, and repack it. Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latest STS jdk - currently 20, soon briefly 21 and a bit alter 22... Should be built in latest live EPEL - epel8 now. We have verified, that such repacked JDKs work fine. == Feedback == == Benefit to Fedora == java maintainers will finally some free time... No kidding - maintenance and *certification* of so much supported JDKs on so much Fedora versions is brutal. By building once, and repack, we will regain cycles to continue support Fedora with all LTS and one STS javas. If we fail to build once and repack everywhere, java maintainers will most likely need to lower the number of JDKs in fedora to system one only. == Scope == * Proposal owners: Technically all jdks (except 8, where some more tuning is needed, and epels for java-latest) are prepared, as they have portable version, and rpms just reapck it. Except tuning up the jdk8 and epel for latest, scope owners are done. * Other developers: There will be needed significant support from RCM and maybe senior fedora leadership to help to finish the build in oldest and enable to repack everywhere<!-- * '''Release engineering: [https://pagure.io/releng/issue/11438 #11438]''' There will be needed significant support from RCM, where I'm actually unsure what they will have to do to enable this. The mas rebuild will not be needed. * Policies and guidelines: AFAIK none (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: All supported JDKS will remain in Fedora in highest possible quality with full QA and certification, and its packagers will not lose their minds. note, that QA will still run on all live fedoras, not only on the builder one. == Upgrade/compatibility impact == The change should be completely transparent to any user. == How To Test == `sudo dnf update/install "java*"` will install expected set of working packages. == User Experience == The change should be absolutely transparent to any user. == Dependencies == To finish this we will need heavy support from RCM, and maybe others. Although there are precedents with such package, they all bites. From SW point of view, the dependence chain is `normal RPMs build requires portable RPMs` and that's all. == Contingency Plan == * Contingency mechanism: It should be stright forward to revert back to building per OS * Contingency deadline: N/A * Blocks release? No. The change can be introduced even on the fly to live distributions. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford

So, the only way I can see to do this would be to have releng manually tag the builds from oldest release into newer ones each time they are built. I do not like this for a number of reasons: * It's more manual work. * It bypasses a bunch of our process. There wouldn't be any bodhi update, so no CI checks, no chance for karma, no updates-testing step (unless there's more work to retag a bunch of times). I'm open to other ideas, but as it is I'm not liking this change.

On 31. 05. 23 1:31, Kevin Fenzi wrote: > So, the only way I can see to do this would be to have releng manually > tag the builds from oldest release into newer ones each time they are > built. I do not like this for a number of reasons: > > * It's more manual work. > * It bypasses a bunch of our process. There wouldn't be any bodhi > update, so no CI checks, no chance for karma, no updates-testing step > (unless there's more work to retag a bunch of times). > > I'm open to other ideas, but as it is I'm not liking this change. If we never actually ship the "build once" builds, and only ship the "repack everywhere" ones, this could be achieved by the maintaines: 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)

The build from (2) will be eventually garbage collected. To prevent that, it might be re-tagged regularly. This is where releng might be able to help by creating a long lived tag to tag this into for preserving.

On Wed, May 31, 2023 at 1:31 AM Kevin Fenzi <kevin(a)scrye.com&gt; wrote: > > So, the only way I can see to do this would be to have releng manually > tag the builds from oldest release into newer ones each time they are > built. I do not like this for a number of reasons: > > * It's more manual work. > * It bypasses a bunch of our process. There wouldn't be any bodhi > update, so no CI checks, no chance for karma, no updates-testing step > (unless there's more work to retag a bunch of times). There's also more problems: This approach would basically opt OpenJDK out of all System-Wide changes, like GCC updates, compiler flag changes, etc. (at least until "Fedora oldstable" catches up to those changes 12 months later).

So, the only way I can see to do this would be to have releng manually tag the builds from oldest release into newer ones each time they are built. I do not like this for a number of reasons: * It's more manual work. * It bypasses a bunch of our process. There wouldn't be any bodhi update, so no CI checks, no chance for karma, no updates-testing step (unless there's more work to retag a bunch of times).

On 30/05/2023 20:37, Aoife Moloney wrote: >   Jdks in fedora are already static, and we repack portable > tarball into rpms. Currently, the portbale tarball is built for each > Fedora and Epel version. Goal here is to build each jdk > (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and > repack in all live fedoras. All Fedora packages must be built from sources (except linux-firmware package of course).

On 31/05/2023 14:53, Jiri Vanek wrote: > It is built from sources of course! > What make you think it is not? > For double ensurenes, see the fesco ticket in proposal. IMO, repackaging prebuilt RPM packages is not building from sources.

On 5/31/23 9:44 AM, Gerd Hoffmann wrote: > On Wed, May 31, 2023 at 03:32:09PM +0200, Vitaly Zaitsev via devel wrote: >> On 31/05/2023 14:53, Jiri Vanek wrote: >>> It is built from sources of course! >>> What make you think it is not? >>> For double ensurenes, see the fesco ticket in proposal. >> >> IMO, repackaging prebuilt RPM packages is not building from sources. > > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't > see how that violates the 'build from source' requirement. > > We do similar things in other cases, see for example shim-unsigned.rpm + > shim.rpm Will user be able to download SRPMS like   dnf download --source java... and get a real source RPM that can be rebuilt or the SRPM will have a prebuilt tarball and the user will need to hunt down the real SRPM, and do things like using a VM or container to built that, for later rebuild the "binray" SRPM from the Fedora repos?

> > take care, >    Gerd _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

On 31/05/2023 15:44, Gerd Hoffmann wrote: > We do similar things in other cases, see for example shim-unsigned.rpm + > shim.rpm Shim is a special case: 1. Shim need to be signed by Microsoft on their own infrastructure and this signature will be built directly into PE file. 2. Shim runs on UEFI, so it can use exception for firmware. > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't > see how that violates the 'build from source' requirement. If the package uses prebuilt blobs (their origin is irrelevant), it violates current Fedora packaging guidelines.

On 31/05/2023 19:24, Daniel P. Berrangé wrote: > Can you point to the specific guideline that this violates ? I know we've > always expected that apps are built from pristine upstream source, but I'm > not finding the specific guideline that describes this right now. This: > All program binaries and program libraries included in Fedora packages > must be built from the source code that is included in the source > package. Source: https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-pac...

>All program binaries and program libraries included in Fedora >packages must be built from the source code that is included in >the source package.

On 31/05/2023 15:44, Gerd Hoffmann wrote: > We do similar things in other cases, see for example shim-unsigned.rpm + > shim.rpm Shim is a special case: 1. Shim need to be signed by Microsoft on their own infrastructure and this signature will be built directly into PE file. 2. Shim runs on UEFI, so it can use exception for firmware. > The prebuilt RPMs are compiled on Fedora infrastructure too, so I don't > see how that violates the 'build from source' requirement. If the package uses prebuilt blobs (their origin is irrelevant), it violates current Fedora packaging guidelines.

== Benefit to Fedora == java maintainers will finally some free time... No kidding - maintenance and *certification* of so much supported JDKs on so much Fedora versions is brutal. By building once, and repack, we will regain cycles to continue support Fedora with all LTS and one STS javas.

Long story short yes, if yo wish to distribute jdk *binary* it have to pass java compliance suite.

In addition, this kit complicne tests are proprietary, close source and licensed.

Long story short yes, if yo wish to distribute jdk *binary* it have to pass java compliance suite.

This was heavily discussed when we moved to portable build in rpms - https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic Long story short yes, if yo wish to distribute jdk *binary* it have to pass java compliance suite.

On 6/1/23 3:51 AM, Richard W.M. Jones wrote: >On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote: >>This was heavily discussed when we moved to portable build in rpms - >>https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic >>Long story short yes, if yo wish to distribute jdk *binary* it have >>to pass java compliance suite. > >It sounds like the problem is the software isn't really open source >because it has some field of use restrictions. The best plan would be >to change this upstream, and if that isn't possible then to remove it >from Fedora. > >Rich. > It is the same discussion about Firefox that is already settled I think. The JVM code is open source, even free software. The trademark isn't. Mozilla doesn't allow anyone to call the browser Firefox without some rules.

Red Hat want to run the tests because Java corporate users want that, so Red Hat does it and at the same time helps to have a more robust Java ecosystem.

On 6/1/23 8:33 AM, Richard W.M. Jones wrote: > On Thu, Jun 01, 2023 at 08:28:18AM -0400, Robert Marcano via devel wrote: >> On 6/1/23 3:51 AM, Richard W.M. Jones wrote: >>> On Wed, May 31, 2023 at 05:27:47PM +0200, Jiri Vanek wrote: >>>> This was heavily discussed when we moved to portable build in rpms - >>>> https://fedoraproject.org/wiki/Changes/JdkInTreeLibsAndStdclibStatic >>>> Long story short yes, if yo wish to distribute jdk *binary* it have >>>> to pass java compliance suite. >>> >>> It sounds like the problem is the software isn't really open source >>> because it has some field of use restrictions.  The best plan would be >>> to change this upstream, and if that isn't possible then to remove it >> >from Fedora. >>> >>> Rich. >>> >> >> It is the same discussion about Firefox that is already settled I >> think. The JVM code is open source, even free software. The >> trademark isn't. Mozilla doesn't allow anyone to call the browser >> Firefox without some rules. > > Both projects involve heavy-handed enforcement of trademarks, but > don't seem to be the same issue.  (I'll leave this to lawyers to > answer definitely though.) > >> Red Hat want to run the tests because Java corporate users want >> that, so Red Hat does it and at the same time helps to have a more >> robust Java ecosystem. > > That's nice, and indeed RHEL ships OpenJDK.  The question is about > what we do in Fedora. > > Rich. > All this change is about the burden of maintaining so many OpenJDK branches as packages in FEdora. Maybe Fedora should stop distributing ancient Java versions as one of our missions is to be cutting edge, maybe we are still encouraging too many projects to stay running on Java 8. I am saying this as some that would be affected if Java 8 isn't packaged anymore, I still need to develop and test some things with Java 8 because at work we have some customers still running ancient hardware and have been a pain to make them move to modern distributions. So I will have to us another universal OpenJDK build (like Temurin) 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.

All this change is about the burden of maintaining so many OpenJDK branches as packages in FEdora. Maybe Fedora should stop distributing ancient Java versions as one of our missions is to be cutting edge, maybe we are still encouraging too many projects to stay running on Java 8. I am saying this as some that would be affected if Java 8 isn't packaged anymore, I still need to develop and test some things with Java 8 because at work we have some customers still running ancient hardware and have been a pain to make them move to modern distributions. So I will have to us another universal OpenJDK build (like Temurin) 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.

Could you explain what certification means? It sounds like you run some very expensive tests, and building is actually fast.

> Am 31.05.2023 um 18:52 schrieb Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org&gt;: > > On 31/05/2023 17:02, David Schwörer wrote: >> Could you explain what certification means? >> It sounds like you run some very expensive tests, and building is actually fast. > > You can't distribute any package named Java or OpenJDK unless it passes the Oracle test suite. > > I think Fedora should drop openjdk package and introduce a new one - coffee-named-language. Then we can get rid of any Oracle tests. Did you ever develop in Java? It doesn't sound like you are even minimally familiar with Java. A little expertise would really be beneficial for devel mailing list.

If you're serious about developing Java applications, you're not going to use an uncertified JDK to do it.

Can you clarify this a bit? It sounds like some versions of the JDK in Fedora will actually be built in EPEL. I feel that all Fedora packages should actually built for Fedora, not RHEL. Also, what exactly does "latest live EPEL" mean - how is 8 the latest? I guess basically, can you further explain/clarify exactly which versions of what OS which JDKs will be built on, and when those versions will change.

Once upon a time, Jiri Vanek <jvanek(a)redhat.com&gt; said: > I have fixed typo in the proposal " Should be built in oldest live EPEL" instead of " Should be built in latest live EPEL", which was wrong. At the moment though, the oldest live EPEL is 7, not 8.

> I do not have hard requirement to build java-latest-openjdk on epel8 > and repack everywhere, but it gave sense. If the hard demand will be > to build also java-latest-opnejdk in oldest fedora, and repack in > all fedoras, and built it in oldest epel, and repack in all epels, > then it gave somehow sesnse too. Although I would conisdered it a > bit wasted cycle, it is acceptable. I think building for Fedora in Fedora would moderate the concerns about old compiler/flags/etc., because the oldest Fedora at any point is about a year old. The oldest EPEL (7) is currently approaching 9 years old, and even the oldest you listed (8) is 4 years old. It would also help with reproducibility. EPEL is built against RHEL, which is not freely available (yes, there are rebuilds, there are free limited developer licenses, etc., but it's not directly easy for someone else to exactly reproduce the EPEL build environment). That's okay for EPEL builds, but I personally feel it would be more acceptable to build Fedora packages on Fedora.

On Wed, May 31, 2023 at 07:38:38PM +0200, Jiri Vanek wrote: >> Can you clarify this a bit? It sounds like some versions of the JDK in >> Fedora will actually be built in EPEL. I feel that all Fedora packages >> should actually built for Fedora, not RHEL. >> >> Also, what exactly does "latest live EPEL" mean - how is 8 the latest? >> >> I guess basically, can you further explain/clarify exactly which >> versions of what OS which JDKs will be built on, and when those versions >> will change. > > > Jdk is designed, to be severely forward comaptible from os where it was built. > So jdk8, 11 and 17 would be build in oldest live fedora, and repacked > everywhere. The idea is to build them on oldest viable system, as we > can guarantee they will run ok in newer Fedroas.. > java-latest-openjdk however, is built also for epel8 and elep9. Thus > logically the oldest system where we can built it to repack it everywhere > is el8. Then it can be reapcked for el8,el9, and all live fedoras. IIRC, RHEL-8 forked from Fedora in circa F28 timeframe. Directly comparing RHEL-8 content to Fedora is a bit of a fools errand since RHEL does rebase certain packages periodically, but a decent chunk of RHEL-8 is 5 years old at this point. The most notable part is the compiler toolchain on RHEL-8 is GCC 8.x, which is 5 major releases behind what F39 rawhide uses, and 4 major release behind what F37 uses. RHEL-8 also has a long lifetime left, and thus so does EPEL8. By building JDK on EPEL8, we're fixing the toolchain for JDK in Fedora on a version already 5 years out of date, and by the time EPEL8 goes away, the toolchain will be 10+ years out of date. By building JDK on the oldest stable Fedora release, we're fixing the toolchain on a version that's never going to be much more then 1 year out of date. Same applies to compiler toolchain flags, though where the flags don't depend on GCC version that can be partially mitigated in the JDK spec. Overall, I find the idea of basing Fedora builds on oldest EPEL quite challenging to accept, due to the age differences. It feels contrary to Fedora goal of always being on, or at least very near, the cutting edge. > I do not have hard requirement to build java-latest-openjdk on epel8 and > repack everywhere, but it gave sense. If the hard demand will be to build > also java-latest-opnejdk in oldest fedora, and repack in all fedoras, and > built it in oldest epel, and repack in all epels, then it gave somehow > sesnse too. Although I would conisdered it a bit wasted cycle, it is > acceptable. IMHO it'd be more palatable for the RHEL (EPEL) build stream to be separate from the Fedora build stream. While RHEL and Fedora share heritage, they are ultimately different distros with different goals and needs.

Il 30/05/23 20:37, Aoife Moloney ha scritto: > This document represents a proposed Change. As part of the Changes > process, proposals are publicly announced in order to receive > community feedback. This proposal will only be implemented if approved > by the Fedora Engineering Steering Committee. > > == Summary == > > This is the last step in > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs > effort. Jdks in fedora are already static, and we repack portable > tarball into rpms. Currently, the portbale tarball is built for each > Fedora and Epel version. Goal here is to build each jdk > (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and > repack in all live fedoras. > If I understand this correctly, this just means that java package built on Fedora x-2 will be tagged also in Fedora x-1, Fedora x and Rawhide. Am I correct?

If so, maybe the proposal needs a better wording rather than "repack in all live fedoras", as that sounds like RPMs are "repacked" in some way, but the truth is that the same RPM is made available in several Fedora repositories.

Mattia _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Aoife Moloney wrote: > As described in > https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; > during last year, packaging of JDKs had changed dramatically. As > described in same wiki page, and individual sub changes and devel > threads, with primary reason this - to lower maintenance and still > keep fedora java friendly. And these changes have made the Fedora Java packages basically useless, because there is really no advantage anymore to be had over just using, e.g., Adoptium builds. Your changes have removed the choice from users to choose between a Java built the upstream way (Adoptium and others) and a Java built according to the Fedora Packaging Guidelines as all Fedora packages are supposed to be (but yours no longer are). > * In first system wide change, we had changed JDKs to build properly > as standalone, portable jdk - the wey JDK is supposed to be built. I > repeat, we spent ten years by patching JDK to become properly dynamic > against system libs, and all patches went usptream, but it become > fight which can not be win This is already against the best practices recommended by the Fedora Packaging Guidelines, and arguably even against a mandatory rule (because you say all the patches allowing unbundling went upstream): https://docs.fedoraproject.org/en-US/fesco/Bundled_Software_policy/ "All packages whose upstreams allow them to be built against system libraries must be built against system libraries." > * as a second step we introduced portable rpms, which do not have any > system integration, only builds JDK and pack final tarball in RPM for > free use. > * In third step - without any noise, just verified with fesco - > https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully > integrated rpms. Instead of this, normal RPMS BUildRequire portable > rpms and just unpack it, and repack it. In short, you build an RPM containing a tarball instead of unpacked files, and then have the final RPM BR that intermediate RPM, untar the tarball, and repackage it. A really ugly hack that goes against any packaging best practices and maybe even subtly violates the letter of the Fedora Packaging Guidelines (it is definitely against the spirit). I do not understand why FESCo approved this hackery. It brings no advantages whatsoever to the user, it just makes the builds take longer overall for no good reason.

Neal Gompa wrote: > Because the alternative is no Java runtime at all, and that's even > less acceptable. I do not see why the way the packaging used to work all these years could not be kept unchanged. The only issues that were pointed out were related to the Java TCK (that it takes too long to run on every build, and that sometimes system libraries cause failures in some obscure test that are hard to debug), to which the obvious answer is to just stop running it and call the package something other than the current java-*-openjdk. (My understanding as a non-lawyer is that it should be enough to change the package Name and the Summary and %description. The java-*-openjdk name could still be Obsoleted/Provided, and the binaries do not have to be renamed either.) Kevin Kofler _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Jiri Vanek wrote: > At elast providing ofjava/openjdk is definitley out of scope. I do not think a Provides would be a trademark violation. It is a part of the standard procedure for renaming a package. But you would have to ask Red Hat Legal for a definite answer. I am not a lawyer. That said, there might not even be a trademark issue at all, at least for "OpenJDK" ("Java" might be different), see Florian Weimer's reply, pointing to: https://openjdk.org/legal/openjdk-trademark-notice.html > As you wrote about the liberty of choice between temurins and fdeoara ona > - can you be a bit more specific? Afaik if the builds are similar, we have > mcuh less possibility of some fedora-specific bug. But it also means that I no longer have the option to use a Java that does not bundle several libraries, possibly including security vulnerabilities,

bloating its size, and likely reducing system integration (there have been concerns about, e.g., worse fontconfig integration in the discussion of your

previous Change proposal). There is now just the "choice" between a Fedora package with everything bundled and third-party packages with also everything bundled. > I once wrote,m that wworked 10years to enable dynamic linking, and yes, > all is upstream, but there are limitations which can not be overtaken - > major is ahead of tie comilation. If you can do it right, you cnanot have > dyanmic linking. Wait, Java does real AOT compilation now? Or are we talking about that strange "feature" you already brought up in the old discussion, where you basically just prepend a JRE to a JAR and ship that as a "compiled" executable? That "feature", to be honest, I had never heard of before you folks brought it up.

As far as I can tell, nobody in the Java world uses it. It breaks the "write once, run anywhere" promise and brings us no real advantage over having the JRE and the JAR separate.

It is definitely not useful for me because our customers all run Windows, not Fedora or any other GNU/Linux. So really it makes no difference for me whether my "AOT-compiled" binaries run only on Fedora ≥ n (dynamic linking) or on all GNU/Linux (static linking), they will not run on our customers' computers anyway, making that "feature" entirely useless either way. We have a few ways to deploy our JARs to our customers, but none of them involves turning them into native executables through (either real or fake as described above) AOT compilation. > The goal should still be to have fedora rpms properly integrated in > fedora, and usable, as any other java onthe world, without hacks. Sorry, but I believe that the old packaging was exactly that, "properly integrated" and "without hacks", whereas I have to politely disagree about the new packaging having those properties.

I haven’t written Java in years, but my understanding is that AOT compilation has three major advantages: 1. It reduces the size of total deliverables because the final executable only includes the libraries it needs.

2. It is the _only_ way to have decent performance on platforms where JIT compilation is forbidden.

3. AOT-compiled apps start up faster and use less memory.

In short, an AOT-compiled application behaves much more like one that is written in a native language like C++,

Keep in mind that this isn't exactly the first time we've done this either: the .NET runtime is similarly screwy for its bootstrap process, and that's split across a couple of source packages. At this point, we hold our noses and hope for the best. At least there's a chance to reduce the pain with .NET over time as the Red Hat .NET folks work to improve upstream. There's basically zero chance for improvement with OpenJDK because of the nature of the upstream and how old and crufty they are.

That's actually a lot better than it was when I helped with dotnet package review and bootstrap with 3.1.

The main worry I have is how we're going to be able to build dotnet for a new architecture when nothing exists. RISC-V is the next big architecture, but the build for that will be difficult.

It would also be good to have packaging guidelines for .NET applications, since there's a number of server and desktop Linux apps written in .NET languages that people would want to bring to Fedora.

Hi, Thanks your thoughts! Neal Gompa <ngompa13(a)gmail.com&gt; writes: > That's actually a lot better than it was when I helped with dotnet > package review and bootstrap with 3.1. Heh. That's very true! 3.1 had at least two source packages that had to be kept in sync. I think you seemed much happier with the 7.0 review? https://bugzilla.redhat.com/show_bug.cgi?id=2142178 > The main worry I have is how we're going to be able to build dotnet > for a new architecture when nothing exists. RISC-V is the next big > architecture, but the build for that will be difficult. I am working with some folks from IBM on this who have had to build .NET on s390x and ppc64le recently. Just like RISC-V, nothing existed for those architectures before IBM started working on it. IBM have some tools to automate this now. They are working on sharing the tools (and their s390x, ppc64le builds) publicly, but there are some non-technical blockers that prevent them. If/when RISC-V support lands in .NET (eg, minimum of https://github.com/dotnet/runtime/issues/36748), we could use those tools (with hopefully minimal changes) to cross compile .NET for RISC-V. I can ask IBM to prioritize making these tools public.

> It would also be good to have packaging guidelines for .NET > applications, since there's a number of server and desktop Linux apps > written in .NET languages that people would want to bring to Fedora. I don't have a great solution for this. There are a few problems here: - .NET applications really, really aren't meant to be built offline. Like other package ecosystems (eg, npm) every .NET application has a ton of dependencies fixed at specific versions. And they are fetched from the internet. There's no clear way to break down the dependency tree so we can start this work. - Unlike ecosystems such as npm where everyone publishes source, .NET packages are binaries without a clear way to go from source -> binary. So even if we could figure out a clear way to slices the dependency tree so we can start building the root packages, it would be a manual process build every package - A subproblem is that lots of libraries only support building on Windows, or through Visual Studio only. We would have to create/port the upstream build scripts. - GUI applications are simply not supported on Linux. .NET has no implementation for this. If you try and use the .NET SDK to build something that uses the GUI APIs, it will simply error out. There's more discussion upstream at https://github.com/dotnet/core/issues/7443 and https://github.com/dotnet/source-build/discussions/2960

As a result of this, I am not sure where to even begin thinking about packaging applications :( Do you have any suggestions on the most important/useful applications that we should look at for prototyping this effort?

This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == This is the last step in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs effort. Jdks in fedora are already static, and we repack portable tarball into rpms. Currently, the portbale tarball is built for each Fedora and Epel version. Goal here is to build each jdk (8,11,17,21,latest (20)) only once, in oldest live Fedora xor Epel and repack in all live fedoras. == Owner == * Name: [[User:jvanek| Jiri Vanek]] * Email: jvanek(a)redhat.com == Detailed Description == As described in https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs ; during last year, packaging of JDKs had changed dramatically. As described in same wiki page, and individual sub changes and devel threads, with primary reason this - to lower maintenance and still keep fedora java friendly. * In first system wide change, we had changed JDKs to build properly as standalone, portable jdk - the wey JDK is supposed to be built. I repeat, we spent ten years by patching JDK to become properly dynamic against system libs, and all patches went usptream, but it become fight which can not be win * as a second step we introduced portable rpms, which do not have any system integration, only builds JDK and pack final tarball in RPM for free use. * In third step - without any noise, just verified with fesco - https://pagure.io/fesco/issue/2907 - we stopped building JDK in fully integrated rpms. Instead of this, normal RPMS BUildRequire portable rpms and just unpack it, and repack it. Now last step is ahead - to build portable LTS JDKs 8,11,17 and 21 in oldest live Fedora, and repack everywhere. java-latest-openjdk, which contains latest STS jdk - currently 20, soon briefly 21 and a bit alter 22... Should be built in latest live EPEL - epel8 now. We have verified, that such repacked JDKs work fine. == Feedback == == Benefit to Fedora == java maintainers will finally some free time... No kidding - maintenance and *certification* of so much supported JDKs on so much Fedora versions is brutal. By building once, and repack, we will regain cycles to continue support Fedora with all LTS and one STS javas. If we fail to build once and repack everywhere, java maintainers will most likely need to lower the number of JDKs in fedora to system one only. == Scope == * Proposal owners: Technically all jdks (except 8, where some more tuning is needed, and epels for java-latest) are prepared, as they have portable version, and rpms just reapck it. Except tuning up the jdk8 and epel for latest, scope owners are done. * Other developers: There will be needed significant support from RCM and maybe senior fedora leadership to help to finish the build in oldest and enable to repack everywhere<!-- * '''Release engineering: [https://pagure.io/releng/issue/11438 #11438]''' There will be needed significant support from RCM, where I'm actually unsure what they will have to do to enable this. The mas rebuild will not be needed. * Policies and guidelines: AFAIK none (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: All supported JDKS will remain in Fedora in highest possible quality with full QA and certification, and its packagers will not lose their minds. note, that QA will still run on all live fedoras, not only on the builder one. == Upgrade/compatibility impact == The change should be completely transparent to any user. == How To Test == `sudo dnf update/install "java*"` will install expected set of working packages. == User Experience == The change should be absolutely transparent to any user. == Dependencies == To finish this we will need heavy support from RCM, and maybe others. Although there are precedents with such package, they all bites. From SW point of view, the dependence chain is `normal RPMs build requires portable RPMs` and that's all. == Contingency Plan == * Contingency mechanism: It should be stright forward to revert back to building per OS * Contingency deadline: N/A * Blocks release? No. The change can be introduced even on the fly to live distributions. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Product Owner Community Platform Engineering Team Red Hat EMEA Communications House Cork Road Waterford _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue