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
