[fedora-java] /usr/lib/jni support in Fedora

[Jiri Vanek]

On 07/29/2014 04:59 PM, Omair Majid wrote:
> * Florian Weimer <fweimer at redhat.com> [2014-07-29 07:31]:
>> On 07/29/2014 01:17 PM, Jiri Vanek wrote:
>>> On 07/29/2014 01:05 PM, Florian Weimer wrote:
>>>> As far as I can tell, currently, System.loadLibrary() is mostly
>>>> unusable for Java libraries because
>>>> they cannot influence the library search path.  If you want to
>>>> transparently load a DSO, you need to
>>>> use System.load() and hard-code the path.  This probably means
>>>> patching upstream sources.
>>>>
>>>> Debian patches the default search path so that System.loadLibrary()
>>>> searches /usr/lib/jni for DSOs
>>>> with native code.  This means that classes which call
>>>> System.loadLibrary() just work, assuming that
>>>> the Debian package installs its DSOs into /usr/lib/jni.
>>>>
>>>> Can we do something similar in Fedora?  We probably want /usr/lib/jni
>>>> and /usr/lib64/jni, for
>>>> consistency with the rest of the system.
>>>
>>> Then the most simple way is to provide symlinks in
>>> java-1.{7,8}.0-openjdk spec
>>>
>> >from /usr/lib/jni | /usr/lib64/jni, -to> /usr/lib/jvm/java..../...  ?
>
>> Is it a good idea to install files from RPMs through a symbolic link?
>
> We could use the alternatives mechanism for this.
we *must*

Those will be slaves of javac
>
>> I
>> suspect it's not, which would mean we'd have to use the upstream default
>> "/usr/java/packages/lib/amd64" in spec files (probably using a macro). If
>> that path is acceptable, it would be fine with me as well, but it looks a
>> bit ugly to me.
>
> We can change (add and remove from) this path in the JDKs that we ship,
> if we have to.

I would like to avoid unnecessary patching here. Maybe this fix is worthy of upstreaming - to 
provide more general search paths?