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.
Kevin Kofler
_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue
