RE: [PATCH 0/3] multiarch support

["Schmidt, Adriaan" <adriaan.schmidt@siemens.com>]

Kiszka, Jan (T CED) <jan.kiszka@siemens.com>, Montag, 6. Februar 2023 14:01:
> On 06.02.23 13:20, Adriaan Schmidt wrote:
> > Hi,
> >
> > this is my first working draft of multiarch support, which extends all
> package
> > recipes (inheriting dpkg-base) with *-compat and *-native variants.
> >
> > My current use case/test subject is meta-iot2050, which contains a patched
> > openssl, needed in the SDK (as -native package), and on the target (as -
> compat).
> > [1] has this patchseries (plus pre-bitbake2 backporting), if someone would
> like to test.
> > In addition, the compat test from the testsuite works (building hello-isar-
> compat).
> >
> > Still missing:
> > - not sure if -native also needs IMAGE_INSTALL logic to convert bitbake to
> debian names
> 
> You mean foo-{compat,native} -> foo:<{compat-arch,host-arch}>? Would be
> sweet.

I'm already doing it for -compat.
With -native, my current use case is the SDK, which is completely in host-arch,
so we don't *need* to pass it with the individual packages. Also there is currently
no way of getting "dpkg --add-architecture <host-arch>" in a target image, so the
only place we can install -native packages is the SDK and the buildchroot if we're
doing cross builds.
So a conversion foo-native -> foo might be convenient (and consistent, so foo-native
is accepted as part of IMAGE_INSTALL, just as foo-compat), or we make it an
explicit foo-native -> foo:<host-arch>.

Adriaan

> > - documentation
> 
> Specifically a RECIPES-API-CHANGELOG entry.
> 
> > - test case for -native (maybe add libhello-native to the SDK?)
> > - probably other things...
> >
> 
> Nice start!
> 
> Jan
> 
> --
> Siemens AG, Technology
> Competence Center Embedded Linux