Nicolas Mailhot wrote:
I want to know the correct JAVA_HOME and PATH settings for all the
possible JVMs when they are installed as alternatives-conforming RPM
packages but are not the system default. Is this documented somewhere?
So, where do I find the answer to the question above regarding the
correct JAVA_HOME and PATH to use a JVM that is not the system default?
If the question is "what is the list of the roots of all the possible
JVMs that may be released for Linux and packaged using jpp conventions"
– no one has the answer because no one knows the JVM list in the first
place.
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?
Given the vendor name, java standard version, build number etc
one can make an educated guess because people tend to use the same
template but there is no absolute naming requirement. The packager must
choose a unique directory name and it must be under %{libdir}/jvm that's
about it.
If the question is "how does a particular jpp-packaged app choose its
JVM" the answer is it follows the JAVA_HOME env var, and which can be
set:
1. in the user environment
2. in app-specific conf file
3. in user-level conf file
4. in system-level conf file
4. or falling all that trying pre-defined fallbacks (meaning java apps
require java or java-devel, if a java package is installed
%{libdir}/jvm/jre must exist and if a java-devel package is installed
ditto for %{libdir}/jvm/java
It's the responsability of the admin or user that overrides JAVA_HOME
instead of letting the scripts fallback to the defaults to make sure
JAVA_HOME is set properly (ie if you set it as something stupid things
will go boom)
No, I wouldn't limit a question like that to just packaged apps. The
main issue is whether everything expected to be under JAVA_HOME is still
in the correct relative position with all the matching binaries in
$JAVA_HOME/bin.
How is the split exports/private directory supposed to relate to that?
Read the documentation bundled with jpackage-utils
$ rpm -q jpackage-utils
jpackage-utils-1.7.3-1jpp.3.fc6
$ man jpackage-utils
No manual entry for jpackage-utils
Does jpackage have its own convention about what to do with
documentation as well?
Fedora Java packaging as it's known today is a JPackage fork
(periodically rebased). The Red Hat Java group originally started from
its own package repository IIRC, but struggled to package the Java world
and decided later to use a JPackage base as its repo was more complete.
And what's the current situation with this now that Fedora and RHEL5
include some stuff that looks jpackage'd but isn't? How do you
control, for example, which tomcat version you install?
How do you control the installed apache version ?
I didn't know anyone offered more than one.
You get the one the
Fedora maintainer selected. Same for Tomcat. You get the one Fedora
selected if you source Fedora, and you get the one JPP selected if you
source JPP. And the version will change from Fedora release to Fedora
release, and JPP release to JPP release.
What if you source both fedora and jpackage repositories? Is that not a
reasonable thing to do? Or you need both tomcat4 and 5 installed on the
same machine?
If you're not happy with the choices you can contribute another
parallel-installable tomcat to Fedora or JPP, they're both projects open
to external contributions.
I did not have any problem installing both tomcat4 and tomcat55 from the
jpackage repo before fedora/RHEL incorporated parts that don't seem to
play well with others.
But speaking as a former Tomcat packager –
it's a beast with tentacular dependencies, so you better allocate a lot
of packaging time.
That's precisely the sort of thing that you want someone else to get
right in the repositories. I can do the easy stuff myself...
If you have more java packaging questions I suggest posting on
jpackage-discuss, and not be offended if the answer is long in coming —
the project is ressource-starved.
No, I'm more interested in the relationship between the embedded
jpackage-looking stuff in fedora/RHEL5 and whether it is intended to
break access to jpackage. Or if they are supposed to work together, how
do you do it?
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
