RE: [PATCH 0/3] multiarch support

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

Kiszka, Jan (T CED) <jan.kiszka@siemens.com>, Dienstag, 7. Februar 2023 14:51:
> 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.

Yes, quick check on my development machin: "dpkg -l *-compat" returns
debhelper-compat, iptables-nftables-compat, oss-compat, and x2goserver-compat.

But that's only a problem if someone wants to rebuild one of those packages,
otherwise they would go into IMAGE_PREINSTALL, which is not modified, and
has packages in "Debian syntax".

In general, with the proposed extension, it could be that bitbake recipes with
names ending in -compat or -native would no longer be allowed. 
I'd have to verify the details, and can check if some kind of workaround is possible.

Adriaan

> Jan
> 
> --
> Siemens AG, Technology
> Competence Center Embedded Linux