Ty Young wrote:
According to
pkgs.org Fedora Rawhide doesn't even have a 32-bit
JRE/JDK
so i'm not sure why the designation is required. 32-bit has been on the
way out for awhile now. If someone wants to make a 32-bit version they
don't need to follow a distros naming convention.
While some packages are not being built for 32-bit x86 at all anymore
because upstream dropped support for it entirely (e.g., the Eclipse stack),
this is not the case for OpenJDK, where upstream still supports compiling it
for 32-bit x86 (they just do not provide Oracle Java binaries for 32-bit x86
anymore).
Fedora also packages nvidia-smi with CUDA libraries and that's
wrong
too. On both Windows and in Ubuntu nvidia-smi comes with the driver. The
driver control panel is also included on both as well. nvidia-xconfig
comes with the driver in Ubuntu.
This is an issue with RPM Fusion or Negativo's repo or wherever you got the
NVidia driver from. (There are unfortunately multiple repositories providing
the driver with different packaging, due to disagreements on how exactly it
should be packaged. The driver is not included in Fedora itself because it
is not Free Software.)
Just because it's the way it has been done doesn't mean
it's the right
way. It's just the easier pill to swallow.
-devel subpackages are how ALL packages that have both a compile-time and a
runtime part are done in Fedora. Only pure compiler packages (e.g., gcc) and
pure runtime-only packages (e.g., all the leaf applications that do not ship
any libraries) are exempt from the split. This is not just a one-time
decision for a single package.
Because the JRE is derived from the JDK but there are use cases
where
just having a JRE standalone is of benefit. The JRE however is being
killed off. Oracle no longer even distributes a JRE anymore with new
Java versions.
"OpenJDK" is more of a source branding than an indication that it's a
JRE/JDK... but yes it is confusing.
But then why are you complaining about the JRE packages being called
"openjdk"? You explained yourself why they are named that way!
Depending on the program, maybe. If a modular program requires a JDK
module then the JDK is going to need to be used. This isn't immediately
obvious until you run the program and see if it spits out a module not
found error.
Applications doing dynamic compilation typically only require the
java.compiler module, which is in the main package, not the javac
executable, which is in the -devel package. There are no modules in the
-devel package.
Granted, no one should ever distribute a modular application via jar
and
expect a user to launch via the the complex command line command. A
modular application is generally used in conjunction with jLink to provide
a bundle... which requires a JDK to make.
It requires a JDK to make at compile time. (In Fedora, you need the -jmods
subpackage, which depends on -devel. The jmod files that jlink needs are not
installed by default even in -devel.) The end users do not need a JDK to run
it. The point of the main (non-devel) packages is to provide what end users
will need to run Java applications.
This specific problem(which branched out of the alternatives one)
here
isn't with alternatives but with which the JRE and JDK are separated at
the package level. I'm not even sure how as an end user/developer I'd
even know -dlevel exists on Fedora Silverblue as dnf search doesn't
exist and
pkgs.org doesn't bring anything up. Is there an alternative
for Silverblue?
This is not specific to Java packaging though. You will also need -devel
packages for C/C++ libraries (or libraries in most other compiled languages)
if you want to compile applications using them.
and again, the JRE is being axed. Once Java 8 hits EOL the only way
to
get a standalone JRE is (maybe?) by compiling it yourself. Oracle
doesn't distribute it anymore.
You can get a prebuilt standalone JRE from several sources. E.g.,
https://adoptopenjdk.net/ lets you choose between a JDK and a JRE download
if you use the "Other platforms" link. (The front page gives you a JDK
directly.)
Kevin Kofler