Hi Aaron, Le 14/10/2022 à 02:05, Aaron M. Ucko a écrit :
Pierre Gruet <p...@debian.org> writes:I have just pushed some changes. I adopted the -- I believe -- least invasive solution by creating a new package libngs-jni which depends on the shared lib package (not the -dev one), only ships a symlink to the shared lib with full version number, and on which the -java package depends. By the way I also made it Architecture: all and ensured it was binNMU-able.That ought to work, thanks, but shouldn't it be Architecture: amd64? We could get away with all as long as the package is otherwise amd64-only, but we may be able to revisit getting it to build on either or both of ncbi-vdb's other supported architectures (arm64 and x32).
Hmm, I did not have in mind that the package is ready for amd64 only. If this is the case, then yes, we should not use Architecture: all at the moment (which is otherwise the general rule for -java packages).
As such, the new -jni package is not Multi-Arch: same as it ships the shared lib symlink in /usr/lib/jni. But if you think it should be, then we could install the symlink in /usr/lib/<triplet>/jni. This is less canonical regarding the Java policy but technically that should be OK.I'm all for Multi-Arch in general, but am content to defer to Java policy in this case.
After giving it some thoughts, I convinced myself it would be better to fit Multi-Arch: same and put the symlink in /usr/lib/<triplet>/jni, which only violates a "should" in the Java policy but is nevertheless done for many packages. Also this architecture-specific path is searched when loads shared libraries from Java code, so I have pushed the change to Salsa.
Cheers, -- Pierre
OpenPGP_signature
Description: OpenPGP digital signature
