Re: [PATCH 0/3] multiarch support

[Jan Kiszka <jan.kiszka@siemens.com>]

On 06.02.23 14:36, Schmidt, Adriaan (T CED SES-DE) wrote:
> 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>.
> 

What now comes to my mind: What will happen if there are real Debian
packages that carry any of those suffixes in their name? There is e.g.
libgdbm-compat4 - that would be only close.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux