Bug#764630: RFS: javatools 0.48 [RC]

[tony mancill]

On 12/14/2014 09:50 AM, Markus Koschany wrote:
> On 12.12.2014 07:05, tony mancill wrote:
> [...]
>> Any concerns from the team?  This is kind of a brute force approach, but
>> seems reasonable.  My question is:
>>
>> Do we feel confident that this the lists below are representative for
>> for jessie?
>>
>>> MULTIARCH_LIBRARY_PATH_32BIT="/usr/lib/jni:/usr/lib/arm-linux-gnueabi/jni:/usr/lib/arm-linux-gnueabihf/jni:/usr/lib/i386-gnu/jni:/usr/lib/i386-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/i386-kfreebsd-gnu/jni:/usr/lib/mips-linux-gnu/jni:/usr/lib/mipsel-linux-gnu/jni:/usr/lib/powerpc-linux-gnu/jni:/usr/lib/powerpc-linux-gnuspe/jni:/usr/lib/sparc-linux-gnu/jni:/usr/lib/x86_64-linux-gnux32/jni:/usr/lib/hppa-linux-gnu/jni:/usr/lib/sh4-linux-gnu/jni:/usr/lib/m68k-linux-gnu/jni"
>>>
>>> MULTIARCH_LIBRARY_PATH_64BIT="/usr/lib/jni:/usr/lib/alpha-linux-gnu/jni:/usr/lib/x86_64-linux-gnu/jni:/usr/lib/aarch64-linux-gnu/jni:/usr/lib/x86_64-kfreebsd-gnu/jni:/usr/lib/powerpc64-linux-gnu/jni:/usr/lib/powerpc64le-linux-gnu/jni:/usr/lib/s390x-linux-gnu/jni:/usr/lib/sparc64-linux-gnu/jni"
>>
> 
> Hi,
> 
> since nobody seems to have any comments, let me chime in here. The list
> above is complete and contains all possible 32bit and 64bit multiarch
> paths. There was one mistake with kfreebsd-64 but this one has been
> already fixed two days ago. As you rightfully wrote above, this is some
> kind of brute force approach but I'm confident that it covers all
> possible scenarios. Now the code checks what kind of JVM is used and
> adds the respective MULTIARCH_LIBRARY_PATH to -Djava.library.path.
> Actually I would prefer that all JREs would handle that by themselves
> but it seems so far only OpenJDK is capable of doing it.
> 
>> Or should jarwrapper honor MULTIARCH_LIBRARY_PATH (or
>> JARWRAPPER_MULTIARCH_LIBRARY_PATH, or similar) in the environment?  Just
>> in case we missed something or something else comes along.  If present,
>> perhaps this could be added after /usr/lib/jni, and before the other
>> components of the path.
> 
> 
> The downside of this approach is that we need to add new multiarch paths
> to jarwrapper whenever a new architecture gets introduced to Debian.
> However I think this is manageable. The purpose of jarwrapper is to set
> up binfmt-misc to run executable jar files. I feel that no further user
> or maintainer interaction should be necessary in addition to that. It
> should just work (TM). So in my opinion it would be better if it did not
> honor any additional environment variables and simply did its job.

[trimming the portion of the email regarding policy - we'll return to
that post-jessie]

I'll buy the statement that it should "just work."  Regarding an upload,
I noticed that there are a few subsequent changes/fixes pushed to the
packaging repo since December 5th.  They don't require any updates to
debian/changelog, since they're all related to this bug.  Is there any
work or testing still in progress?  Any concerns with an upload for the
state of the package as of 94c25581?

Thank you,
tony


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20141221/b011e5e6/attachment.sig>