| Message ID | 20230206122050.337270-1-adriaan.schmidt@siemens.com |
|---|---|
| Headers | show |
| Series | multiarch support | expand |
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
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.