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.