On 07/30/2014 11:39 AM, Andrew Haley wrote:
Ideally we'd want to have this discussion with Java upstream.
Okay, I can bring it up there, but I'm not sure yet what Fedora's needs
are, so I think it's premature to bring it up upstream.
Depending on a Fedora-local patch to the search path means that if
people build their own OpenJDK or install Oracle Java, their programs
will stop working. So, we must not do that.
I suspect that using a JDK not packaged by us needs a changed invocation
of the launcher anyway, and throwing the appropriate
-Djava.library.path= setting would only be a minor complication,
compared to all the other things that aren't quite right by default.
If a symlink at /usr/java/packages/lib/amd64 to wherever is
allowable,
and I see no reason why it should not be, then we don't need to patch
OpenJDK. We could make /usr/java/packages/lib/amd64 a real directory,
and populate it with symlinks to the packages or make it just a
symlink to /usr/lib64/jni ; again, I don't think it matters.
If there's consensus to introduce /usr/lib64/jni with compatiblity
symlinks under /usr/java/packages/lib, then we don't need any upstream
changes, just a java-filesystem package which installs the symbolic
links, and a change to the Java packaging guidelines.
Debian uses (or will soon use) multiarch paths, and these seem difficult
to compute outside of a Debian environment, which is why I believe that
changing the upstream default to include appropriate /usr/lib/jni
directories could be challenging. Maybe we could just use the
non-multiarch directories, and Debian can keep patching the defaults,
but that doesn't seem ideal to me, either.
--
Florian Weimer / Red Hat Product Security