https://bugzilla.redhat.com/show_bug.cgi?id=1187713 Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|fedora-review? |fedora-review+ --- Comment #20 from Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> --- (In reply to jiri vanek from comment #19) > Last thing we disagree is the arch/noarch lib/path/lib64 convention. > > I'm still keeping my approach, beacuse I somehow feel that what you wont me > to do is wrong: > > - from fedora guidelines the multilib jni packages are not supported > - my main package contains both jar and nativelib => not noarch > > if I split natvie and java files to two packages and made jar "multilib" > (search in both lib and lib64) then yes, your case you shown with dnf will > work. However, > - the multilib is not supposed to be supported > - there is real danger that jar run in 64 jvm will load 32b library or vice > versa (afaik it is why jni is not supported multilib) > - the jar without so and vice versa dont have sense. OK. This feels to be a suboptimal situation to me, but I don't see an easy solution. I was wrong in thinking that the packages for the two architectures can be installed simultaneously when the patch to use .load() is modified to not include an architecture-specific path. It turns out that the jar contains headers which include a timestamp, so the resulting jar files are different anyway. A work-around could be added, but it's not trivial. I believe all issues have been fixed or determined to be unfixable. Package is APPROVED. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review