[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Goal: Increased Modularity?



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 gmail com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]