https://bugzilla.redhat.com/show_bug.cgi?id=1187713

Zbigniew JÄ™drzejewski-Szmek <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|fedora-review?              |fedora-review+



--- Comment #20 from Zbigniew JÄ™drzejewski-Szmek <[email protected]> ---
(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
[email protected]
https://admin.fedoraproject.org/mailman/listinfo/package-review

Reply via email to