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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Reply via email to