RE: [PATCH 0/3] multiarch support

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

Schmidt, Adriaan, Dienstag, 7. Februar 2023 15:45:
> 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>.

v2 will also convert foo-native to 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.

Indeed, bitbake recipes can't have names ending in -compat or -native, and there
seems to be no simple way around it.
But since recipe names are independent of the Debian packages they produce,
we can still re-compile (or generate) Debian packages with those endings,
just need use a different name for the recipe and be careful with the
DEPENDS and IMAGE_INSTALL...

Adriaan

> 
> Adriaan
> 
> > Jan
> >
> > --
> > Siemens AG, Technology
> > Competence Center Embedded Linux
> 
> --
> You received this message because you are subscribed to the Google Groups
> "isar-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isar-users+unsubscribe@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/isar-
> users/AS4PR10MB5318B9ACBAF27FA2470FFA93EDDB9%40AS4PR10MB5318.EURPRD10.PROD.OU
> TLOOK.COM.