RFR (S): JDK-8222778: Packaging Tool (JEP 343) on Linux/AArch64

[Dmitry Chuyko]

On 7/18/19 12:19 AM, Dmitry Chuyko wrote:
> ..................
>>> 2. LinuxDebBundler.getArch() now maps only x86_64 to amd64, x86 is 
>>> still
>>> mapped to i386, and other archs map to themselves.
>>>
>>> 3. In tests, new method getRpmArch() was added to linux/base/Base.java,
>>> it maps JVMs os.arch to default rpmbuild arch. Multiple tests were
>>> modified to use that method instead of "x86_64" in rpm file name. Some
>>> timeouts were increased.
>> +        if ("arm".equals(arch))
>> +            return "armv7hl";
>>
>> Is this actually correct? How do you know it's not, say, armv7hf? I 
>> would
>> have thought there must be some better way to get the RPM arch. Isn't
>> running /bin/arch right on your systems?
>
> Using $(arch) is an interesting question. For now implementation 
> decides what kind of bundle to create looking at JVM binary arch. This 
> should guarantee that the bundle will fit the same arch of host and 
> some compatible architectures (app will be be installable and 
> runnable). And it also mean current tests may fail if host and VM 
> archs are different (because packages won't be found while may be 
> created and may be working).
>
> 'arvmv7hl' is a common build environment/target for arm port and looks 
> like a compatible option. We may look into VM binary metadata though 
> to get exact build arch.
>
Currently jpackage relies on underlying tool defaults at the host. 
rpmbuild makes difference, so then arch is armv7l packages may be for 
example armv7hl. In tests exact rpm arch can be determined using cpu 
flags or the tool itself.

So we can add a bit of rpmbuild logic in getRpmArch(), it actually can 
be made by getting _target_cpu from rpmbuild.

-Dmitry


>
>
>>