Fedora, Packaging, Java, and Shrooms

[Ty Young]

Hi,

I'm thinking of switching to Fedora 30 Silverblue(once it comes out of beta
anyway) from Arch linux. One of the requirements is to be able to install,
compile from source and easily switch between JDK builds. However, Fedora
fails to meet these requirements so badly I'm fairly certain whoever
packaged and approved the various Java RPMs was on shrooms(partial offense,
sorry but this is nuts).

Confused? Never installed Java in Fedora before? Lets go down the rabbit
hole together!

Firstly, the java version installed by doing:

rpm-ostree install java

gets you Java 8. I understand that Red Hat is providing support until
sometime 2023 however I feel it to be much more appropriate that this
either gives the latest LTS(11 currently) or the newest  JDK(12 currently).
Even if still technically support, installing a JRE that old isn't likey to
be advised. Even in Ubuntu 18.10  you get Java 11.

OK, so just specify the specific versions that you actually need and
everything will work as it should. No big deal, right? Nope.

alternatives(see: https://fedoraproject.org/wiki/Java), which is supposed
to allow you to switch between Java versions, flat out doesn't work. You
tell it to list all alternatives like so:

alternatives --display java

and the command executes without printing anything. Odd. Let's just check
what's in /usr/lib/jvm for a sanity check:

ls /usr/lib/jvm

java-11-openjdk-11.0.2.7-7.fc30.x86_64
java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64
java-1.8.0-openjdk-1.8.0.201.b09-6.fc30.x86_64
jre
jre-11
jre-11-openjdk
jre-11-openjdk-11.0.2.7-7.fc30.x86_64
jre-12
jre-12-openjdk
jre-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64
jre-1.8.0
jre-1.8.0-openjdk
jre-1.8.0-openjdk-1.8.0.201.b09-6.fc30.x86_64
jre-openjdk

...

What. I only installed Java 8, Java 11, and Java 12. Installing Java on
either Ubuntu and Arch doesn't duplicate any JRE/JDK like this.

OK, so lets open it in nautilus:

nautilus /usr/lib/jvm

Those aren't duplicates, all but 3 folders are system links? What? This
should be the one and only system location for JRE/JDK(s). What's going on
here? Where do they go?

They go to /etc/alternatives. I guess this is supposed to be how
alternatives finds alternative JRE/JDK installs. Ubuntu doesn't have to do
this for update-alternatives nor does Arch's archlinux-java script but...
OK. This is insanely complicated for no real good reason.

But wait, we aren't done yet because what's being linked to from
/usr/lib/jvm isn't a file, it's... another system link. Back to the 3 non
system links in /usr/lib/jvm which have horrendously long and complex
folder names. Is calling them
java-<version>-<jre/jdk>-<oracle/zulu/openjdk> not enough?

To top this "what" fest off, the JRE/JDK folders in /etc/alternatives
aren't even named properly.  That is to say,   "jre" is attached to the
front even if what's being linked is a JDK. Yes, a JDK contains a JRE but
it's still horribly confusing for no good reason. Like, imagining if
alternatives did work, does it list duplicate entries for each JRE/JDK? For
example:

jre_11
java-11-openjdk

which(again) system link to the same JDK install.

What shroom induced insanity is this? Why does alternatives not work?

[Nicolas Mailhot]

Le 2019-04-11 13:40, Ty Young a écrit :

Hi,

>  What shroom induced insanity is this? Why does alternatives not work?
Java is not "just" a system directory, it's a set of coordinated 
commands, some of those shared between the jre and the jdk, with the set 
varying slightly between Java versions, JDK provider, etc.

Writing good alternative rules given all those can be quite challenging 
and brain-damaging (alternative rules must upgrade gracefully to the 
next package versions)

I'm sure the maintainers of the Java packages would be delighted to have 
someone to review all the alternative rules and fix up all the warts 
that crept in since Java 1.3 times (back in my day, once you got 
alternatives to work for a new jdk, you tried very hard to forget the 
experience). Certainly, all the standardizing on openjdk after SUN sank 
should have simplified the mess a little.

-- 
Nicolas Mailhot

[Ty Young]

> Java is not "just" a system directory, it's a set of
> coordinated 
commands, some of those shared between the jre and the jdk, with the
set
varying slightly between Java versions, JDK provider, etc.

What you are (primarily) describing is the path export variable to the java
binary which is located in a JRE/JDK install.

In Ubuntu and Arch Linux this is done via a "default" system link in
/usr/lib/jvm that links to the configured system wide JRE/JDK located in
the same directory(/usr/lib/jvm). Surely both you and the Fedora Java
maintainers know this or have at least thought of it?

> Writing good alternative rules given all those can be quite
> challenging 
and brain-damaging (alternative rules must upgrade gracefully to the
next package versions)

Again, just system link to the correct folder like every other distro.
alternatives doesn't need to concern itself with specific content. It could
be empty or copy/pasted as far as it *should* care. As long as it follows
the java-* format you can get a list of all JRE/JDK installs regardless of
the name and have "default" system link point to it.

> I'm sure the maintainers of the Java packages would be delighted
> to have 
someone to review all the alternative rules and fix up all the warts
that crept in since Java 1.3 times (back in my day, once you got
alternatives to work for a new jdk, you tried very hard to forget the
experience). Certainly, all the standardizing on openjdk after SUN sank
should have simplified the mess a little.

This has nothing to do with how the folders are named. See:

https://www.digitalocean.com/community/tutorials/how-to-install-java-with...

under "managing java".

[Michal Konecny]

Hi,

firstly i recommend to use Fedora toolbox [0] for this kind of things on 
Silverblue (it's part of Silverblue already).

Secondly, isn't this what modules are meant for? I'm not sure if there 
is one for JDK on Fedora.

Regards,
Michal Konecny

[0] - https://github.com/debarshiray/toolbox

On 4/11/19 1:40 PM, Ty Young wrote:
>  Hi,
>
>  I'm thinking of switching to Fedora 30 Silverblue(once it comes out of 
>  beta anyway) from Arch linux. One of the requirements is to be able to 
>  install, compile from source and easily switch between JDK builds. 
>  However, Fedora fails to meet these requirements so badly I'm fairly 
>  certain whoever packaged and approved the various Java RPMs was on 
>  shrooms(partial offense, sorry but this is nuts).
>
>  Confused? Never installed Java in Fedora before? Lets go down the 
>  rabbit hole together!
>
>  Firstly, the java version installed by doing:
>
>  rpm-ostree install java
>
>  gets you Java 8. I understand that Red Hat is providing support until 
>  sometime 2023 however I feel it to be much more appropriate that this 
>  either gives the latest LTS(11 currently) or the newest JDK(12 
>  currently). Even if still technically support, installing a JRE that 
>  old isn't likey to be advised. Even in Ubuntu 18.10  you get Java 11.
>
>  OK, so just specify the specific versions that you actually need and 
>  everything will work as it should. No big deal, right? Nope.
>
>  alternatives(see: https://fedoraproject.org/wiki/Java), which is 
>  supposed to allow you to switch between Java versions, flat out 
>  doesn't work. You tell it to list all alternatives like so:
>
>  alternatives --display java
>
>  and the command executes without printing anything. Odd. Let's just 
>  check what's in /usr/lib/jvm for a sanity check:
>
>  ls /usr/lib/jvm
>
>  java-11-openjdk-11.0.2.7-7.fc30.x86_64
>  java-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64
>  java-1.8.0-openjdk-1.8.0.201.b09-6.fc30.x86_64
>  jre
>  jre-11
>  jre-11-openjdk
>  jre-11-openjdk-11.0.2.7-7.fc30.x86_64
>  jre-12
>  jre-12-openjdk
>  jre-12-openjdk-12.0.0.33-1.ea.1.rolling.fc30.x86_64
>  jre-1.8.0
>  jre-1.8.0-openjdk
>  jre-1.8.0-openjdk-1.8.0.201.b09-6.fc30.x86_64
>  jre-openjdk
>
>  ...
>
>  What. I only installed Java 8, Java 11, and Java 12. Installing Java 
>  on either Ubuntu and Arch doesn't duplicate any JRE/JDK like this.
>
>  OK, so lets open it in nautilus:
>
>  nautilus /usr/lib/jvm
>
>  Those aren't duplicates, all but 3 folders are system links? What? 
>  This should be the one and only system location for JRE/JDK(s). What's 
>  going on here? Where do they go?
>
>  They go to /etc/alternatives. I guess this is supposed to be how 
>  alternatives finds alternative JRE/JDK installs. Ubuntu doesn't have 
>  to do this for update-alternatives nor does Arch's archlinux-java 
>  script but... OK. This is insanely complicated for no real good reason.
>
>  But wait, we aren't done yet because what's being linked to from 
>  /usr/lib/jvm isn't a file, it's... another system link. Back to the 3 
>  non system links in /usr/lib/jvm which have horrendously long and 
>  complex folder names. Is calling them 
>  java-<version>-<jre/jdk>-<oracle/zulu/openjdk> not enough?
>
>  To top this "what" fest off, the JRE/JDK folders in /etc/alternatives 
>  aren't even named properly. That is to say,   "jre" is attached to the 
>  front even if what's being linked is a JDK. Yes, a JDK contains a JRE 
>  but it's still horribly confusing for no good reason. Like, imagining 
>  if alternatives did work, does it list duplicate entries for each 
>  JRE/JDK? For example:
>
>  jre_11
>  java-11-openjdk
>
>  which(again) system link to the same JDK install.
>
>  What shroom induced insanity is this? Why does alternatives not work?
>
>
>
>
>
>
>  _______________________________________________
>  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://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]

[Ty Young]

> firstly i recommend to use Fedora toolbox [0] for this kind of things
> on 
Silverblue (it's part of Silverblue already).

Not everything can easily be done in a containerized environment. The game
"Minecraft" for example needs a system JRE in order to run as it is written
in Java and is installed via a jar file(old launcher anyway). While not
ideal, I don't think this is against the Fedora Silverblue containerized
idea. That is to say, Java is a semi dynamic extension of the base system
and NOT an application.

Yes, it is possible to bundle a Java program with a JRE/JDK in a Flatpak
and distribute that. The problem is that it both takes up significant disk
space compared to if you were to just use the system JDK and makes it
difficult to switch between JRE/JDK versions if need be.


> Secondly, isn't this what modules are meant for? I'm not sure
> if there is 
one for JDK on Fedora.

Java 9 modules you mean? Java 9 modules are a way to create a JDK bundle
with your app with significantly less fat as only what is needed is
included. For distribution of a program written in Java, sure that works as
long as the program is modeler... but not all are.

That's the thing: I need to switch between a "server" build of the JDK(uses
MORE memory, what every distro ships) and a "client" build(uses less
memory, needs to be compiled from source) as well as any other custom
builds I might compile or install from time to time. I'd imagine this could
be done via the build script but that just complicates things and is
specific to the computer the software is being compiled on. It's easier to
just quit the IDE(netbeans in my case), switch versions, and start it up
again.

The only problem is that the current running JRE/JDK is being (potentially)
pulled from under any running Java application that is utilizing the system
JRE/JDK and a newer or older version is replacing it. This, however, is a
problem in Flatpak applications as well and there doesn't seem to be any
solution other than to somehow completely load the application and all of
it's library dependencies(Java, Nvidia libs, etc) in memory. Java is not
system critical just as the Flatpak runtimes are not system critical.

[Gerald Henriksen]

On Thu, 11 Apr 2019 08:08:21 -0500, you wrote:

> >Secondly, isn't this what modules are meant for? I'm not
> sure if there is
> one for JDK on Fedora.
>
> Java 9 modules you mean?  
No, Fedora Modules, an alternative to rpms I think.

[Kevin Kofler]

Ty Young wrote:
>  alternatives(see: https://fedoraproject.org/wiki/Java), which is
> supposed
>  to allow you to switch between Java versions, flat out doesn't work. 
This is probably due to limitations in Silverblue. The Fedora Java packaging 
was designed for normal Fedora, at a time where Silverblue did not even 
exist as a concept.

No matter how aggressively Silverblue is being marketed at the moment, it is 
still pretty experimental and inconvenient to use.

You will probably have a much better experience using a standard, non-atomic 
Fedora installation.

>  They go to /etc/alternatives. I guess this is supposed to be how
>  alternatives finds alternative JRE/JDK installs. Ubuntu doesn't have to do
>  this for update-alternatives nor does Arch's archlinux-java script but...
>  OK. This is insanely complicated for no real good reason. 
The idea is that alternatives should only write to /etc, never to /usr. 
Writing to /usr is a bad idea (and incidentally, will likely never work in 
Silverblue). So the alternatives in /usr must be symlinks to 
/etc/alternatives, and /etc/alternatives contains the user-configurable 
symlinks to the real binaries.

>  But wait, we aren't done yet because what's being linked to
> from
>  /usr/lib/jvm isn't a file, it's... another system link. Back to the 3 non
>  system links in /usr/lib/jvm which have horrendously long and complex
>  folder names. Is calling them
>  java-<version>-<jre/jdk>-<oracle/zulu/openjdk> not enough? 
The naming allows installing multiple versions of the same major version, 
and in particular also 32-bit vs. 64-bit versions.

>  To top this "what" fest off, the JRE/JDK folders in
> /etc/alternatives
>  aren't even named properly.  That is to say,   "jre" is attached to the
>  front even if what's being linked is a JDK. 
No. If you just install the java-*-openjdk package, you get only the JRE 
part of OpenJDK. The JDK part is in java-*-openjdk-devel.

The way this works is that the -devel package adds:
* files to the versioned directory under /usr/lib/jvm AND
* additional alternatives settings for jdk, javac, etc. (and normally, javac
  inherits the setting for jdk which itself inherits the jre setting, but
  you can force a mixed version mess if you really want that).

>  Yes, a JDK contains a JRE but it's still horribly confusing for
> no good
>  reason. Like, imagining if alternatives did work, does it list duplicate
>  entries for each JRE/JDK? For example:
>  
>  jre_11
>  java-11-openjdk
>  
>  which(again) system link to the same JDK install. 
jre_11 is any Java 11 implementation. java-11-openjdk is any minor version 
of OpenJDK 11, so more specific. Different applications may want to have 
differently stringent requirements. The alternatives are set up to allow 
them to specify exactly what they want.

>  What shroom induced insanity is this? 
It's not insane, it's complex because there are so many people with so many 
different requirements for Java stuff (and it was designed at a time where 
the situation was even worse, with Sun Java, IBM Java, and the Free as in 
Speech but limited-functionality GCJ stack, which was the best we had in 
Free Software before OpenJDK and IcedTea).

>  Why does alternatives not work? 
Probably a bug or missing feature in Silverblue.

        Kevin Kofler

[Ty Young]

On 4/11/19 11:30 PM, Kevin Kofler wrote:
>  Ty Young wrote:
> > alternatives(see: https://fedoraproject.org/wiki/Java), which is supposed
> > to allow you to switch between Java versions, flat out doesn't work.
>  This is probably due to limitations in Silverblue. The Fedora Java packaging
>  was designed for normal Fedora, at a time where Silverblue did not even
>  exist as a concept.
>
>  No matter how aggressively Silverblue is being marketed at the moment, it is
>  still pretty experimental and inconvenient to use.
>
>  You will probably have a much better experience using a standard, non-atomic
>  Fedora installation. 

My reason for wanting to switch to Fedora Silverblue is for the safe 
system upgrades and easy system recovery. Without either of those, I'd 
just stick with Arch. The way software is (sometimes incorrectly, 
nvidia-smi in CUDA for example) split into multiple packages in Fedora 
isn't a headache worth dealing with for me without something to make it 
more appealing... and Fedora Silverblue is very appealing.


> > They go to /etc/alternatives. I guess this is supposed to be how
> > alternatives finds alternative JRE/JDK installs. Ubuntu doesn't have to do
> > this for update-alternatives nor does Arch's archlinux-java script but...
> > OK. This is insanely complicated for no real good reason.
>  The idea is that alternatives should only write to /etc, never to /usr.
>  Writing to /usr is a bad idea (and incidentally, will likely never work in
>  Silverblue). So the alternatives in /usr must be symlinks to
>  /etc/alternatives, and /etc/alternatives contains the user-configurable
>  symlinks to the real binaries. 

Which it does but no alternatives show up even when downloading from 
Fedora's repos. Is there no post installation scripts that properly 
registers everything? If not, then how are there symbolic links in 
/etc/alternatives? What are they even for?



> > But wait, we aren't done yet because what's being linked to from
> > /usr/lib/jvm isn't a file, it's... another system link. Back to the 3 non
> > system links in /usr/lib/jvm which have horrendously long and complex
> > folder names. Is calling them
> > java-<version>-<jre/jdk>-<oracle/zulu/openjdk> not enough?
>  The naming allows installing multiple versions of the same major version,
>  and in particular also 32-bit vs. 64-bit versions. 

Realistically speaking, is there ever going to be multiple versions from 
the same vendor distributed by Fedora? Other Linux distros just do:


java-<version>-openjdk


for each version and it seems to work fine. If someone compiles from 
source or downloads from somewhere they are probably going to have a 
different vendor branding or some other custom format like:


java-11-zulujdk


or something.


> > To top this "what" fest off, the JRE/JDK folders in /etc/alternatives
> > aren't even named properly.  That is to say,   "jre" is attached to
> the
> > front even if what's being linked is a JDK.
>  No. If you just install the java-*-openjdk package, you get only the JRE
>  part of OpenJDK. The JDK part is in java-*-openjdk-devel. 

Which isn't clear by the package name. It's ambiguous. Given the shift 
from distributing jar programs to modular app bundles one might 
reasonable expect any java implementation after Java 9 to include a full 
JDK by default which includes a full JRE. It isn't like anything is 
going to break by doing this because, again, the JDK is a JRE. Any non 
modeler programs will still work.


>  The way this works is that the -devel package adds:
>  * files to the versioned directory under /usr/lib/jvm AND
>  * additional alternatives settings for jdk, javac, etc. (and normally, javac
>     inherits the setting for jdk which itself inherits the jre setting, but
>     you can force a mixed version mess if you really want that). 

Is that really a good idea? There may be use cases where one might need 
different JRE and JDK of the same version. Java 8 jPackager(deprecated 
in newer Java versions) might for example allow a standalone JRE, 
reducing some dead weight as opposed to bundling with the full JDK.


> > Yes, a JDK contains a JRE but it's still horribly confusing for no good
> > reason. Like, imagining if alternatives did work, does it list duplicate
> > entries for each JRE/JDK? For example:
> >
> > jre_11
> > java-11-openjdk
> >
> > which(again) system link to the same JDK install.
>  jre_11 is any Java 11 implementation. java-11-openjdk is any minor version
>  of OpenJDK 11, so more specific. Different applications may want to have
>  differently stringent requirements. The alternatives are set up to allow
>  them to specify exactly what they want. 

I have never personally run into such a situation. As long as 
/usr/bin/java links to a valid Java binary it doesn't really seem to 
matter. Given that no other Linux distro does this AFAIK, this can't be 
common practice.


> > What shroom induced insanity is this?
>  It's not insane, it's complex because there are so many people with so many
>  different requirements for Java stuff (and it was designed at a time where
>  the situation was even worse, with Sun Java, IBM Java, and the Free as in
>  Speech but limited-functionality GCJ stack, which was the best we had in
>  Free Software before OpenJDK and IcedTea). 

Fair enough.Given that only Java 8 and newer is available via Fedora's 
repos and things have calmed down a bit, is the complexity still worth 
it though?


>
>> Why does alternatives not work?
> Probably a bug or missing feature in Silverblue.
>
>          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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]

[Nicolas Mailhot]

Le vendredi 12 avril 2019 à 01:21 -0500, Ty Young a écrit :
>  
>  Fair enough.Given that only Java 8 and newer is available via
>  Fedora's 
>  repos and things have calmed down a bit, is the complexity still
>  worth it though? 
You still have OpenJ9 vs OpenJDK, LTS vs non LTS, completely free
software build vs supported proprietary build (Fedora does not ship the
later but some Fedora derivatives do and there is a wish for them to be
able to do it without butchering the Fedora-inherited filesystem
layout).

So yes, it is probably possible for someone motivated to invent a
better java alternative setup, but it will be a lot of work, with a lot
of constrains (one of those, being able to upgrade existing setups to
the new system gracefully)

-- 
Nicolas Mailhot

[Kevin Kofler]

Ty Young wrote:
>  Which it does but no alternatives show up even when downloading from
>  Fedora's repos. Is there no post installation scripts that properly
>  registers everything? If not, then how are there symbolic links in
>  /etc/alternatives? What are they even for? 
There are such post-installation scripts, but it looks like they are not 
working in Silverblue. This is something that needs to be addressed in 
Silverblue.

>  Realistically speaking, is there ever going to be multiple versions
> from
>  the same vendor distributed by Fedora? 
32-bit vs. 64-bit is one example (which is why the directory names contain 
the CPU architecture, e.g., x86_64).

> > No. If you just install the java-*-openjdk package, you get only
> the JRE
> > part of OpenJDK. The JDK part is in java-*-openjdk-devel.
>  
>  Which isn't clear by the package name. It's ambiguous. 
This is how almost all software in Fedora is packaged: the main package 
contains the files required at runtime, the -devel package the files 
required to compile software against the package.

And the ambiguous naming is really upstream's fault, because there is no 
such thing as "OpenJRE".

>  Given the shift from distributing jar programs to modular app bundles
> one
>  might reasonable expect any java implementation after Java 9 to include a
>  full JDK by default which includes a full JRE. It isn't like anything is
>  going to break by doing this because, again, the JDK is a JRE. Any non
>  modeler programs will still work. 
Modular Java programs do not need a full JDK either, a JRE is sufficient. 
The full JDK is only needed to compile software from source.

>  Is that really a good idea? There may be use cases where one might
> need
>  different JRE and JDK of the same version. Java 8 jPackager(deprecated
>  in newer Java versions) might for example allow a standalone JRE,
>  reducing some dead weight as opposed to bundling with the full JDK. 
This is supported by the alternatives setup. (It is the reason why there are 
separate jre and jdk alternatives, though the latter tracks the former by 
default, but you complained about exactly that complexity…) But what such 
standalone JRE should Fedora ship? Again, there is no OpenJRE. We can only 
ship the JRE subset of OpenJDK as the default JRE.

        Kevin Kofler

[Ty Young]

On 4/12/19 10:40 AM, Kevin Kofler wrote:
>  Ty Young wrote:
> > Which it does but no alternatives show up even when downloading from
> > Fedora's repos. Is there no post installation scripts that properly
> > registers everything? If not, then how are there symbolic links in
> > /etc/alternatives? What are they even for?
>  There are such post-installation scripts, but it looks like they are not
>  working in Silverblue. This is something that needs to be addressed in
>  Silverblue.
>
> > Realistically speaking, is there ever going to be multiple versions from
> > the same vendor distributed by Fedora?
>  32-bit vs. 64-bit is one example (which is why the directory names contain
>  the CPU architecture, e.g., x86_64). 

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.


> >> No. If you just install the java-*-openjdk package, you get only the JRE
> >> part of OpenJDK. The JDK part is in java-*-openjdk-devel.
> > Which isn't clear by the package name. It's ambiguous.
>  This is how almost all software in Fedora is packaged: the main package
>  contains the files required at runtime, the -devel package the files
>  required to compile software against the package. 

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.


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.


>  And the ambiguous naming is really upstream's fault, because there is no
>  such thing as "OpenJRE". 

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.


> > Given the shift from distributing jar programs to modular app bundles one
> > might reasonable expect any java implementation after Java 9 to include a
> > full JDK by default which includes a full JRE. It isn't like anything is
> > going to break by doing this because, again, the JDK is a JRE. Any non
> > modeler programs will still work.
>  Modular Java programs do not need a full JDK either, a JRE is sufficient.
>  The full JDK is only needed to compile software from source. 

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. 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.


> > Is that really a good idea? There may be use cases where one might need
> > different JRE and JDK of the same version. Java 8 jPackager(deprecated
> > in newer Java versions) might for example allow a standalone JRE,
> > reducing some dead weight as opposed to bundling with the full JDK.
>  This is supported by the alternatives setup. (It is the reason why there are
>  separate jre and jdk alternatives, though the latter tracks the former by
>  default, but you complained about exactly that complexity…) But what such
>  standalone JRE should Fedora ship? Again, there is no OpenJRE. We can only
>  ship the JRE subset of OpenJDK as the default JRE. 

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?


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.

[Gerald Henriksen]

On Fri, 12 Apr 2019 17:24:46 -0500, you 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. 
According to Koji, Java is indeed still built in a 32bit version,

https://koji.fedoraproject.org/koji/buildinfo?buildID=1241271

> 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. 
Fedora doesn't package nvidia-smi - the binary Nvidia driver is not
allowed in Fedora.  If you have issues with how it is packaged then
take it up with the 3rd party providers who have packaged it.

But before you do so I suggest you take a look at the packaging
guidelines to see if there might actually be a valid reason for the
way things are done...

https://docs.fedoraproject.org/en-US/packaging-guidelines/

> 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. 
What Oracle does or doesn't do isn't relevant, as Fedora is packaging
OpenJDK from sources, and has done so from the beginning of OpenJDK.

> 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? 
If you spent some time learning Fedora, and how Fedora packages
things, or asked questions, you would learn/know that Fedora separates
out everything into a runtime package and a devel package.

Or alternatively explore koji.fedoraproject.org and see what packages
are created for each source rpm.

As for Silverblue, as mentioned it's a work in progress (and like any
open source project likely welcoming of assistance if that intersts
you).

[Kevin Kofler]

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

[Colin Walters]

On Thu, Apr 11, 2019, at 7:41 AM, Ty Young wrote:
>  Hi,
>  
>  I'm thinking of switching to Fedora 30 Silverblue(once it comes out of 
>  beta anyway) from Arch linux. One of the requirements is to be able to 
>  install, compile from source and easily switch between JDK builds.  
Bigger picture, as another person commented the overall design push of Silverblue (and
FCOS) is to use containers - I personally do all of my development inside `toolbox` where
I install things with dnf (among other tools) and try to keep my host small.  (Though I
have package layered libvirt, tilix and sway for example).

>  However, Fedora fails to meet these requirements so badly I'm
> fairly 
>  certain whoever packaged and approved the various Java RPMs was on 
>  shrooms(partial offense, sorry but this is nuts). 
To be fair this is really rpm-ostree conflicting with alternatives:
https://bugzilla.redhat.com/show_bug.cgi?id=1657367

Also, more generally anything that tried to "snapshot" system state
would get into a mess with things in /usr referencing parts of /var.
So fixing alternatives to keep state in /etc or /usr solely without
involving /var would benefit everything.  For example I bet
alternatives is broken with https://github.com/openSUSE/transactional-update
too (though it might be differently broken).

rpm-ostree breaking alternatives is one of a few examples of why we basically need two
systems for a while.

(Though it's interesting of course since once you invest a lot in something like
'toolbox' you start thinking about snapshots of that, i.e. a clean separation of
the container image and your state, and that would drive the container image more towards
the "ostree style" filesystem layout, i.e. /var/home in your containers too, but
that'd bring the alternatives problem back inside the container)

[Nicolas Mailhot]

Le vendredi 12 avril 2019 à 13:16 -0400, Colin Walters a écrit :
>  
>  On Thu, Apr 11, 2019, at 7:41 AM, Ty Young wrote:
>  > Hi,
>  > 
>  > I'm thinking of switching to Fedora 30 Silverblue(once it comes out
>  > of 
>  > beta anyway) from Arch linux. One of the requirements is to be able
>  > to 
>  > install, compile from source and easily switch between JDK builds. 
>  
>  Bigger picture, as another person commented the overall design push
>  of Silverblue (and FCOS) is to use containers  
Well everyone’s design push nowadays is to use containers. The problem
is not choosing to use containers, the problem is to manage all the
container interfaces and overlays, so they actually give the expected
benefits.

Java alternatives are a perfect example, how a much simpler tech like
symlinks, can grow into a complex monster, once you've added up all the
desired policy constrains. Simple direct setups are easy. Declining
them to the level of complexity of modern IT without losing ground is
hard.

-- 
Nicolas Mailhot

[Neal Gompa]

On Fri, Apr 12, 2019 at 1:17 PM Colin Walters <walters(a)verbum.org&gt; wrote:
>  On Thu, Apr 11, 2019, at 7:41 AM, Ty Young wrote:
>  > Hi,
>  >
>  > I'm thinking of switching to Fedora 30 Silverblue(once it comes out of
>  > beta anyway) from Arch linux. One of the requirements is to be able to
>  > install, compile from source and easily switch between JDK builds.
>
>  Bigger picture, as another person commented the overall design push of Silverblue (and
> FCOS) is to use containers - I personally do all of my development inside `toolbox` where
> I install things with dnf (among other tools) and try to keep my host small.  (Though I
> have package layered libvirt, tilix and sway for example).
>  
Containers are still pretty bad for complex graphical software
development, though I imagine not many people do that with Java these
days...

>  > However, Fedora fails to meet these requirements so badly
> I'm fairly
>  > certain whoever packaged and approved the various Java RPMs was on
>  > shrooms(partial offense, sorry but this is nuts).
>
>  To be fair this is really rpm-ostree conflicting with alternatives:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1657367
>
>  Also, more generally anything that tried to "snapshot" system state
>  would get into a mess with things in /usr referencing parts of /var.
>  So fixing alternatives to keep state in /etc or /usr solely without
>  involving /var would benefit everything.  For example I bet
>  alternatives is broken with https://github.com/openSUSE/transactional-update
>  too (though it might be differently broken).
>  
openSUSE's transactional-update system handles alternatives fine
because it handles /etc merging and such. So even user settings in
/etc are preserved properly.

Only rpm-ostree has major issues with chunks of the ecosystem because
it doesn't implement some aspects that librpm has, and the filesystem
lockdown is more rigid.

-- 
真実はいつも一つ！/ Always, there's only one truth!

[Ty Young]

On 4/12/19 12:16 PM, Colin Walters wrote:
>  On Thu, Apr 11, 2019, at 7:41 AM, Ty Young wrote:
> > Hi,
> >
> > I'm thinking of switching to Fedora 30 Silverblue(once it comes out of
> > beta anyway) from Arch linux. One of the requirements is to be able to
> > install, compile from source and easily switch between JDK builds.
>  Bigger picture, as another person commented the overall design push of Silverblue (and
> FCOS) is to use containers - I personally do all of my development inside `toolbox` where
> I install things with dnf (among other tools) and try to keep my host small.  (Though I
> have package layered libvirt, tilix and sway for example). 

Which is fine and all. I'm sure toolbox covers some developers needs 
nicely. My point is that not everything can be done in containers and 
having add-on system software that can be switched between 
on-the-fly(for both users or developers) isn't some completely unheard 
of idea. I don't think this is a case of Fedora Silverblue not being 
capable of being used for mainstream use but rather a pain point that 
needs to be hammered out.


> > However, Fedora fails to meet these requirements so badly I'm fairly
> > certain whoever packaged and approved the various Java RPMs was on
> > shrooms(partial offense, sorry but this is nuts).
>  To be fair this is really rpm-ostree conflicting with alternatives:
>  https://bugzilla.redhat.com/show_bug.cgi?id=1657367
>
>  Also, more generally anything that tried to "snapshot" system state
>  would get into a mess with things in /usr referencing parts of /var.
>  So fixing alternatives to keep state in /etc or /usr solely without
>  involving /var would benefit everything.  For example I bet
>  alternatives is broken with https://github.com/openSUSE/transactional-update
>  too (though it might be differently broken).
>
>  rpm-ostree breaking alternatives is one of a few examples of why we basically need two
> systems for a while. 
Maybe only capture symbolic links in the ostree image and redirect to a 
shared directory?


>
> (Though it's interesting of course since once you invest a lot in something like
'toolbox' you start thinking about snapshots of that, i.e. a clean separation of
the container image and your state, and that would drive the container image more towards
the "ostree style" filesystem layout, i.e. /var/home in your containers too, but
that'd bring the alternatives problem back inside the container)
> _______________________________________________
> 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://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]