> Jiri Vanek wrote: > > Unfortunately, your mail does not clarify all that much for me. I actually > see several contradictions, e.g.: > > > vs. > > > so "putting [the binary] onto some other system", "eg on super custom > opensuse", is exactly what you want to be able to do. I do not see it as condradiction, But I agree it was poor formulation. In rpm world, including the statically linked jdk, it is not a goal to have portable /usr/lib/jvm/java* But it will be a partially consequence, if the whole https://fedoraproject.org/wiki/MoveFedoraJDKsToBecomePortableJDKs is implemented. You will be indeed able to copy that somewhere else. and it will work. But , repeating, it is not a goal. > > > There will necessarily be a delay between a security hole being fixed in a > commonly used library such as zlib or freetype and the fix making it into an > OpenJDK release. Really, not necessarily. As writen in this thread several times. > > And in the case you describe (where the system version is not fixed yet when > OpenJDK upstream is), switching to the bundled version is the wrong thing to > do, you need to get the security update to the Fedora library pushed out as > quickly as possible, so everything benefits from the security fix. (Maybe > you or another OpenJDK maintainer needs provenpackager privileges for that.) > We can release for fedora nytime we need wish or need. Both from random hash in upstream repo or from release tag with any custom patch on top of it. And we do it pretty commonly. If needed, if there is necessary or interesting patch, or if it is simply demanded. RH OpenJDK QA team is doing quite a good work in ensurring those remains healthy > > SHOULD still means you need to justify why you want to do otherwise. I do > not see a valid reason in this case. > I agree, but to lower TCK rate to aprox 1/4 and to lower bug rate and cancelded features becasue of dynamic linking should be enough. > > In the rsync case, it is actually also disputed whether this is really > necessary (I doubt that there is really no better way to solve their > problem), but at least there is a concrete issue there, which (IIRC) is wire > compatibility of checksums of compressed blocks. > > > I have not seen any issues with the dynamic builds over years of using > Fedora OpenJDK RPMs for production use. Right. Because throng of excellent engineers was taking care about it:) > > > And that is a lot of work you are trying to commit to, in the same mail > where you are stating that you already have a hard time keeping up with the > workload in the current state. I do not see how you can realistically get > this done without significant delays for security fixes in the bundled > libraries, especially if you are going to wait for TCK results for each and > every security backport to a bundled library. Interesting point. You are right, that I wil be TCKing 1/4 of builds, but most likely 2x or even 3x more often. Still it is aprox 1/2 of current load. In addition, the higher ranking CVEs in the mentioned libraries - jpg, png... are very rare. Highlight - no crypto libraries will be bundled. They will remain dynamically loaded in runtime, because you can swithc crypto providers. And each crypto provider have different backend. > > > And as I wrote above, that is entirely the wrong way to go at it. > > > OpenH264 is actually *not* part of Fedora, as Red Hat is not allowed to ship > it under the patent license, only Cisco is. So it gets built on the Fedora > Koji in an unpublished tag, shipped from there to Cisco, and Cisco releases > it in a third-party repository that is enabled by default in the Fedora > repository configuration (but can be disabled by the user, e.g., I have it > disabled because the FFmpeg H.264 decoder and the x264 encoder, both from > RPM Fusion, are simply the better H.264 implementations). That is a very > special arrangement that is due to patent issues. > > I do not see how OpenJDK qualifies for such a special arrangement, and even > if it does, what you want is exactly the opposite of what OpenH264 is doing: > You want to get a build *into* Fedora repositories that is not built in the > respective Koji buildroot (it may be built in Koji, but you want to build it > once for all Fedora releases, so not in the release's buildroot), whereas > OpenH264 is actually built *in* the release's Koji buildroot and then > shipped *elsewhere*. > > > This is an exception specific to firmware (it is treated as content, not > code), which explicitly does *not* apply to anything running on the CPU in > kernel space or user space. > > > And I sure hope it would not be granted, as I do not see a valid rationale > for such a blatant guideline violation at all. > > > Andrew Hughes says you actually do not have to certify each binary, so > logically one of you must be mistaken. That sounds like misunderstending, becasue I'm the one whoruns them, and I run them for all bninaries. If i'm reading the license wrongly allthose years, with support and agreement from OpenJDK community, ..it would be nasty face palm. > > > At that point, I do not see the value of keeping Java alive in Fedora at > all. Better work with Adoptium to get their builds into an RPM repository > (hosted by them), if this kind of vanilla all-bundled builds are what you > want. That is very close to the final state of things: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! There is an effort of identical reproducible binaries in openjdk usptream. That says, that you build on several systems identical binaries, and thus you can TCK only one of them. That was created by co work of Red hat, Debian, Adotpium and others, to solve the TCK issue. Still I'm afraid it will never work properly with dynamic linking. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! So in ideal world, fedora, debia, adoptium.. will share identical binary, buuilt in theirs own build root. There is still long run to ideal world. > > And maybe if you orphan the Fedora RPM, someone might pick it up. As a > Fedora packager and OpenJDK user, I might even sign up to comaintain, though > the time I can spend on it is limited. For your own sanity, dont do that. But seeing this discussion, it may evolve like this. > > I think the whole Java SIG needs to be restarted from scratch anyway, as > there is very little left from the Java ecosystem that was once packaged in > Fedora. OpenJDK is almost the last piece that is remaining. Fabio did severe attempt todo so. I had best intentions to support him. Forsome reason it do nto work. Meybe to much live versions of to much to small dependencies. But python world is similar. HArd to say what is so wrong. > > > Fedora does *not* package binary driver blobs. We do package binary firmware > blobs. The distinction between a driver and a firmware is that the driver > runs on the CPU, the firmware runs on the peripheral. (Then there is the > early boot firmware that runs before the OS (UEFI/BIOS) or gets loaded at > early boot to fix CPU bugs (CPU microcode), those are special cases.) > OpenJDK is *not* firmware. (And for that matter, it is not a driver either.) > You are right, sorry for bad formualtion. I ment firmware. Also you are right that openjdk is not an firmware. Still it may be granted an exception based on certification reasons and on furhter viability of OpenJDK. If I wouldbe nitpicking, both openjdk and firnmware runss directly in on iron :) /joke > > I have been developing in Java for a living for more than 8 years now. I > have never needed any other JDK than the OpenJDK RPMs from the Fedora > repository. So I have no idea what developers you are talking about. jimage? Grail vm and MAndrel/Quarkus? > > > I take it that those "standalone binary native images" really just bundle a > static java binary with the bytecode into an executable? Moreover correct. > > And what if I want to build the code on Fedora for a customer running > Windows, can I do that with this feature? It does not sound like I can. > Where I work, some of us developers run GNU/Linux (several different > distributions, I run Fedora) and some run Windows, the customers typically > all run Windows (though of course we could easily support customers running > GNU/Linux, as we do have all the JNI libraries and wrapper scripts in place > for us GNU/Linux-using developers). The ability to build once and run > anywhere is one of the reasons we are using Java to begin with. You are describing it pretty well. And from your comment one would guess why would anyody need and native image. Still they does. And I would like to no longer exclude this feature from Fedora. > > In any case, we have never used this feature at work so far. I was not even > aware that it exists at all. We deliver Java code in 2 ways: 1. as JARs in a > ZIP or tarball (for anything that needs to run on the customer's > infrastructure), or 2. as a web service in Tomcat hosted on our servers > (which run Debian and the OpenJDK and Tomcat from the standard Debian > repositories). For JARs we deliver to our customers, we require a systemwide > JRE installation (and we can point them to the Adoptium Windows binaries if > they need a specific recommendation – as I wrote above, the customers > typically run Windows). > > > Well yes, that is what I do for the JNI shared objects we ship, too (and > mock is a great tool for that). But if you want such a build, then use a > non-distro OpenJDK build, not a distro one. Right, sometimes non-distro jdk is necessary. So why nt to have proper distro-jdk, which will allow you to do all? > > > Has it not already? OpenJDK is essentially the last piece that is left and > your proposal would make that package entirely uninteresting and pointless > too (by making it no different from Adoptium Temurin and the like). Except being part of fedora and thus in koji build root. > > > Maybe at this point withdrawing would be the most honest thing to do? IMHO, > we need either new people willing to bring the Java ecosystem (and that > includes Maven, Eclipse and its platform, NetBeans and its platform, etc.) > back to Fedora, following Fedora rules and guidelines, and not constantly > trying to work around them (see the module-only packages in the past, and > now this proposal and its followups), or we need to admit failure and just > drop Java from Fedora altogether (and focus on getting a third-party > repository delivering Adoptium Temurin binaries up ASAP as a replacement / > upgrade path). That may be an option. Thank you for seyng it clearly. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
