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!
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
> 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.
(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
It is used by other projects e.g. http://pkgs.fedoraproject.org/cgit/rpms/hadoop.git/tree/hadoop.spec