Why does macros.jpackage in jpackage-utils-1.6.3 on FC4 still use
%{_prefix}/lib/jvm references while
jpackage.org macros.jpackage in
jpackage-utils-1.6.4 (1.6.3 too allegedly) uses %{_libdir}/jvm?
The really confusing part is that FC4 seems to have picked up
jpackage-utils up _after_ the change was made in the
jpackage.org
version!? (around 1.6.3 when the chagelog lists the change at 1.6.2).
The end result is that the FC4 x86_64 gcj-compat package is in
/usr/lib/jvm rather than /usr/lib64/jvm. The unfortunate thing though is
that the link part of the alternative slaves also end up pointing at
/usr/lib/jvm.
I hit this while trying to finish off the Jpackage jdk cleanups I
started a while back. Updating to jpackage-utils 1.6.4 from
jpackage.org
then trying to install a x86_64 Jdk built against it fails if the
gcj-compat package is installed as the alternatives link names are
different:
1:java-1.5.0-sun ###########################################
[ 14%]
link /usr/lib/jvm-exports/jre incorrect for slave jre_exports
(/usr/lib64/jvm-exports/jre jre_exports)
The culprit being:
--slave /usr/lib64/jvm-exports/jre jre_exports
/usr/lib64/jvm-exports/jre-1.5.0-sun
.. which of course conflicts with the link name already installed
against "jre_exports" for gcj-compat which lists jre_exports as being a
link from /usr/lib/jvm-exports/jre.
The workaround is to stick with the jpackage-utils in FC4 I guess. Still
it's a good example of how mixing JPackage and FC4 can cause problems.
Carwyn