Nicolas Mailhot wrote:
OK, but how about the answer for the known universe of JVM's included in
the fedora/RHEL repositories plus the jpackage repository, including
the ones that don't actually contain the JVM, but do determine the
location where it will be installed?
For the FLOSS ones you can use yum tricks
For the non-FLOSS ones you have to assemble them yourself starting from
the non-free material @jpp, and you can check the paths at the same
time.
A jpp-style repository does *not* maintain a central JVM list. That's
how it was done before I wrote the "new" guidelines in 2003 and it was
hell to maintain. In a jpp-style repository any jvm that drops
directories in the right place may be used through alternatives, but the
rest of the system need not care about the jvms that may or may not be
packaged this way.
I could have sworn I ran into dependencies on specific JVM versions when
trying to install some packages from the jpackage repo. How can that be
if you don't keep track of the JVMs themselves? Or if the packages are
supposed to be usable with unpackaged JVMs?
If you want to bring back central lists from the dead you're welcome to
try, but anyone who touched pre-1.5 jpp won't follow you. For more
information, read jpackage-discuss archives around march 2003.
I don't particularly care how the files are managed or where they live.
I'm just trying to learn how to find what alternatives are available
and how to access them when certain apps require different JVMs and you
want to run them at the same time - and I haven't found much
documentation on the topic.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
