Bug 1420433

Summary:	leveldbjni new package with /lib64/libleveldbjni.so, instead of in /META-INF/native/linux64/ in /usr/lib/java/leveldbjni-linux.jar
Product:	[Fedora] Fedora	Reporter:	Michael Vorburger <vorburger>
Component:	leveldbjni	Assignee:	gil cattaneo <puntogil>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	java-sig-commits, puntogil, skitt
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-08 18:11:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Michael Vorburger 2017-02-08 15:55:45 UTC

Description of problem:

[Initial Bug Description filed by Java developer who may be getting some RPM related terminology wrong; readers, feel free to edit to clarify.]

For https://bugzilla.redhat.com/show_bug.cgi?id=1420383, for https://bugs.opendaylight.org/show_bug.cgi?id=7742, we need a package of leveldbjni (see https://github.com/fusesource/leveldbjni) that is "native", not a "Java package", which lays down libleveldbjni.so into /lib64/ instead of having it in /META-INF/native/linux64/ in /usr/lib/java/leveldbjni-linux.jar

This could be either a completely new package, which personally I would find clearer to avoid any confusion with the current "java" package leveldbjni, or perhaps folks more familiar with this decide to extend the existing leveldbjni package for this; whatever works for you works for me, as long as it solves the requirement shown below

Version-Release number of selected component (if applicable): master

Steps to Reproduce, as per https://github.com/fusesource/leveldbjni/issues/90:

1. git clone git:fusesource/leveldbjni.git
2. cd leveldbjni
3. If https://github.com/fusesource/leveldbjni/pull/89 is not yet merged to master, then: git remote add vorburger https://github.com/vorburger/leveldbjni/; git fetch vorburger; git checkout vorburger/test
4. mvn test -P\!linux64

Actual results:

cat leveldbjni-tests/target/surefire-reports/org.fusesource.leveldbjni.tests.LevelDBTest.txt

testLevelDB(org.fusesource.leveldbjni.tests.LevelDBTest)  Time elapsed: 0.021 sec  <<< ERROR!
java.lang.UnsatisfiedLinkError: Could not load library. Reasons: [no leveldbjni in java.library.path]


Expected results:

sudo dnf install <name-of-whatever-new-package-this-will-build>
mvn test -P\!linux64
LevelDBTest passed!

Comment 1 Lon Hohberger 2017-02-08 16:36:08 UTC

netty native JNI for epoll (for example) also stores things in the installed jars instead of /lib64 - maybe we need to tweak the test(s) ?

./usr/lib/java/netty/netty-all.jar
./usr/lib/java/netty/netty-transport-native-epoll.jar
./usr/lib/java/netty/netty-transport-native-epoll-linux-x86_64.jar

Comment 2 Michael Vorburger 2017-02-08 16:51:24 UTC

> netty native JNI for epoll (for example) also stores things in the
> installed jars instead of /lib64 - maybe we need to tweak the test(s) ?

No, native libraries must be where the system, like all native apps but Java too, expects them to be (like /etc/ld.so.conf => /etc/ld.so.conf.d/*.conf, ldconfig -p and all that stuff).  The test doesn't need to be tweaked.  We need a new libleveldbjni RPM package which lays it down there, that's the goal of this issue.

Comment 3 gil cattaneo 2017-02-08 18:02:38 UTC

(In reply to Michael Vorburger from comment #0)
> Description of problem:
> 
> [Initial Bug Description filed by Java developer who may be getting some RPM
> related terminology wrong; readers, feel free to edit to clarify.]
> 
> For https://bugzilla.redhat.com/show_bug.cgi?id=1420383, for
> https://bugs.opendaylight.org/show_bug.cgi?id=7742, we need a package of
> leveldbjni (see https://github.com/fusesource/leveldbjni) that is "native",
> not a "Java package", which lays down libleveldbjni.so into /lib64/ instead
> of having it in /META-INF/native/linux64/ in
> /usr/lib/java/leveldbjni-linux.jar

I do not agree. this is a JNI library

Comment 4 gil cattaneo 2017-02-08 18:09:05 UTC

It is used by other projects e.g. http://pkgs.fedoraproject.org/cgit/rpms/hadoop.git/tree/hadoop.spec